New API version released 2021-01-25

Add transition timestamps for submission resource

In the previous version you were unable to determine when a submission was transitioned to a particular state. Now we have added last_transitioned_to_STATE_at timestamps for all states (except new - use: submitted_at) to the submission resource. They have also been added to the list of fields for the fields[submission] parameter. This means that you can determine when a submission was transitioned, how long it remained in a particular state, and how your team is doing moving a submission through its lifecycle.

New fields:

  • last_transitioned_to_not_applicable_at
  • last_transitioned_to_not_reproducible_at
  • last_transitioned_to_out_of_scope_at
  • last_transitioned_to_resolved_at
  • last_transitioned_to_triaged_at
  • last_transitioned_to_unresolved_at
  • last_transitioned_to_wont_fix_at

Add options to programs fields parameter

Reward Range

On the /programs endpoint you were able to include current_brief.target_groups.reward_range, but were unable to control the fields on a reward_range. Now the fields[reward_range] parameter is available to reduce the fields returned by included reward_ranges.

Target

On the /programs endpoint you were able to include current_brief.target_groups.targets, but were unable to control the fields on a target. Now the fields[target] parameter is available to reduce the fields returned by included targets.

TargetGroup

On the /programs endpoint you were able to include current_brief.target_groups, but were unable to control the fields on a target_group. Now the fields[target_group] parameter is available to reduce the fields returned by included target_groups.

Add options to programs include parameter

Organization

On the /programs endpoint you were previously unable to include=organization. Now the include=organization parameter is enabled to return the organization resource associated with the program’s organization relationship.

Submissions

On the /programs endpoint you were previously unable to include=submissions. Now the include=submissions parameter is enabled to return an array of submission resources associated with the program’s submissions relationship.

Add options to submissions fields parameter

Comment

On the /submissions endpoint you were able to include comments, but were unable to control the fields on a comment. Now the fields[comment] parameter is available to reduce the fields returned by included comments.

MonetaryReward

On the /submissions endpoint you were able to include monetary_rewards, but were unable to control the fields on a monetary_reward. Now the fields[monetary_reward] parameter is available to reduce the fields returned by included monetary_rewards.

Payment

On the /submissions endpoint you were able to include monetary_rewards.payments, but were unable to control the fields on a payment. Now the fields[payment] parameter is available to reduce the fields returned by included payments.

TargetGroup

On the /submissions endpoint you were able to include program.current_brief.target_groups, but were unable to control the fields on a target_group. Now the fields[target_group] parameter is available to reduce the fields returned by included target_groups.

Add options to submissions include parameter

Assignee

On the /submissions endpoint you were previously unable to include=assignee, and since there is no root identities endpoint there was no way to obtain the resource. Now the include=assignee parameter is enabled to return the identity resource associated with the submission’s assignee relationship.

Claim Ticket

On the /submissions endpoint you were previously unable to include=claim_ticket. Now the include=claim_ticket parameter is enabled to return the claim_ticket resource associated with the submission’s claim_ticket relationship. Claim ticket has now also been added to the included response schema. Note that the claim_ticket token and URL are only available when the submission is first created.

Remove invalid top-level parameters

In the previous version we allowed any common top level parameters for all endpoints even if they were unused. Now unused top level parameters will return a 400 error if included.

GET requests

GET requests allowed attributes and relationships as top level parameters, these have been removed from all GET requests.

GET requests for a single resource e.g. GET /submissions/{id} allowed filter, page, and sort as top level parameters, these have been removed and are now only available on ‘index’ endpoints e.g. GET /submissions.

POST / PATCH requests

Requests using a post body allowed fields, include, filter, page, and sort as top level parameters, these have been removed as they were unused.

Remove additional properties from POST /claim_tickets

On the POST /claim_tickets endpoint you were previously allowed to include any properties not defined in the schema of the root data object of the post body. This has been updated to not allow any properties other than type, attributes, and relationships. Including any other property in the object will now result in a 400 error.

Remove program_groups from program

Program groups were an allowed field and include parameter on the /programs endpoints, but did not actually include the resource since it was not a valid relationship on the program resource.

Example 1: api.bugcrowd.com/programs?fields[program]=program_groups

Example 2: api.bugcrowd.com/programs?include=program_groups

Example 3:

POST api.bugcrowd.com/programs
--data '{
  "data": {
    "type": "program",
    "attributes": { "code": "new-program", "name": "new program" },
    "relationships": {
      "organization": { "data": { "type": "organization", "id": "ORG ID" } },
      "program_groups": {
        "data": [
          { "type": "program_group", "id": "GROUP ID" }
        ]
      }
    }
  }
}'

All of these examples now result in a 400 error stating that program_groups is not an allowed parameter.

Remove reward_range from submissions fields parameter

On the /submissions endpoint you were able to use the fields[reward_range] parameter, but were unable to include reward_ranges. Now the fields[reward_range] parameter has been removed since it was not used. Future requests to the /submissions endpoint using the fields[reward_range] parameter will return a 400 error.

Remove submission from targets fields parameter

On the /targets endpoint you were able to use the fields[submission] parameter, but were unable to include submissions. Now the fields[submission] parameter has been removed since it was not used. Future requests to the /targets endpoint using the fields[submission] parameter will return a 400 error.

Change submission relationship on POST /claim_tickets to has_many

In the previous version for the /claim_tickets endpoint, the submission relationship in the POST parameters is a single object under the key submission however in the resource schema for the claim ticket it can have many submissions.

Now the relationship key is submissions which is an array with a maximum of 1 submission in it.

Change error message for POST /monetary_rewards

In the previous version, when attempting to create a monetary_reward with an amount greater than what is available in the prize pool, the following error would be returned:

{
  "title": "Unprocessable Entity",
  "status": "422",
  "detail": "Unable to save: Reward due to Amount There is not enough money remaining in the bounty prize pool - Please contact Bugcrowd."
}

In the new version the error will be returned as:

{
  "title": "Unprocessable Entity",
  "status": "422",
  "detail": "Unable to save: Reward due to Amount There is not enough money remaining in the bounty prize pool - Please transfer additional funds through the Accounting tab."
}

This is because previously you needed to contact Bugcrowd to add money to the prize pool, but now non-staff users can deposit to their prize pool themselves.

Change order of include lists

Programs

The order of allowed values has changed in the error message when providing an invalid value for the include parameter on the /programs endpoint.

Example:

Before

The property '#/include/0' value 'invalid_resource' did not match one of the following values:
current_brief, current_brief.target_groups, current_brief.target_groups.targets,
current_brief.target_groups.reward_range, program_groups.

After

The property '#/include/0' value 'invalid_resource' did not match one of the following values:
current_brief, current_brief.target_groups, current_brief.target_groups.reward_range,
current_brief.target_groups.targets.

Note that program_groups was removed as part of a separate change.

Organizations

Similar order change to the include parameter on the /organizations endpoint.

Before

The property '#/include/0' value 'invalid_resource' did not match one of the following values: targets, programs.

After

The property '#/include/0' value 'invalid_resource' did not match one of the following values: programs, targets.

Submissions

The order of allowed values has changed in the error message when providing an invalid value for the include parameter on the /submissions endpoint.

Example:

Before

The property '#/include/0' value 'invalid_resource' did not match one of the following
values: activities, program, program.current_brief, program.current_brief.target_groups,
program.organization, comments, comments.author, cvss_vector, duplicates, duplicate_of,
file_attachments, monetary_rewards, monetary_rewards.payments, researcher, target.

After

The property '#/include/0' value 'invalid_resource' did not match one of the following
values: activities, assignee, claim_ticket, comments, comments.author, cvss_vector,
duplicates, duplicate_of, file_attachments, monetary_rewards, monetary_rewards.payments,
program, program.current_brief, program.current_brief.target_groups, program.organization,
researcher, target.

Note that assignee and claim_ticket were added as part of a separate change.

Scope programs relationship for included organization resources

In a previous version it was possible to use the /submissions endpoint to include program.organization and see the number of programs in the organization and their ids through the programs relationship on the organization resource.

For example, if there were 5 programs in an organization, but you only had access to 2 of them, you could still see the ids of the other 3. In future versions this is no longer possible since the programs relationship returned on the organization resource is limited to only the accessible programs.

Visit bugcrowd.com