Decide Trust Center access from Jira or any other system

A prospect asks to see your SOC 2 report. In the app the request lands in the Trust Center access inbox and somebody decides it there. Many security teams would rather decide it where they already decide access: a Jira project, a ServiceNow queue, an access-governance tool.

This guide connects the two. The request becomes a ticket, a person decides it in the ticket, and the ticket’s transition approves or rejects the request through the API. The visitor gets their link exactly as if the decision had been made in the app.

You need: a key with trust-center-access:read and trust-center-access:write (how to get one). If you want to choose specific documents, also trust-center-content:read.

The key and its two scopes

trust-center-access:read reads the inbox. trust-center-access:write decides it, and it is never implied by the read scope: a key that only mirrors requests into a dashboard cannot start letting people in. Mint the write scope only into the key that makes decisions.

A key can only carry a scope its issuer holds, so the person who mints it must be allowed to decide access requests in the app.

Note

A decision made with the key is the key’s. The app shows it as Decided via API key «name», the audit trail records the key, not a person, as the actor, and the request carries decidedVia: "api" and decidedByApiClientId. Give the key a name your reviewers will recognise, such as Jira – security access.

Find out about new requests

Two ways, and you can use both.

Webhook. Subscribe a webhook to trustcenter.access_requested. It fires when a request does not match any of your auto-approval rules and is waiting for a person. Its data carries accessRequestId and nothing personal; fetch the request for the details. This is a premium webhook event: Enterprise plans include it, and GET /v1/webhooks/triggers tells you whether yours does. See Webhooks.

Polling. Works on every plan:

curl -sS "https://api.vendorica.com/v1/trust-center/access-requests?status=pending&limit=50" \
  -H "Authorization: Bearer $VENDORICA_API_KEY"

Newest first, offset-paginated. Keep the ids you have already ticketed so a request that is still pending on the next poll does not open a second ticket.

Read one request

curl -sS "https://api.vendorica.com/v1/trust-center/access-requests/$REQUEST_ID" \
  -H "Authorization: Bearer $VENDORICA_API_KEY"

GET /v1/trust-center/access-requests/{id} returns the visitor’s name, email, company and reason, the country and city the request came from, and requestedResources: restricted documents the visitor asked for by name, with their titles.

Caution

Everything the visitor typed is a claim. The name, the address and the employer are self-asserted by an anonymous submitter. The location is observed, but it is a hint, not proof: a VPN or a corporate egress puts it somewhere the person is not. Put this in the ticket so whoever decides knows what they are looking at.

Choose the documents

An approval grants one of three scopes:

scope	Grants
omitted, or "all"	every gated document that is not restricted, which is what an approval in the app grants by default
"all_gated_plus_selected"	that, plus the restricted documents named in resourceIds
"selected"	only the documents named in resourceIds

Get ids from GET /v1/trust-center/resources (scope trust-center-content:read). isRestricted: true marks the documents a standard approval leaves out, such as a penetration test you only share by name. When the visitor asked for restricted documents, their ids are already in requestedResources.

An unpublished or unknown id refuses the whole approval with a 400 rather than granting less than you asked for.

Approve or reject

1. Approve, optionally with your own reference:

   curl -sS -X POST \
     "https://api.vendorica.com/v1/trust-center/access-requests/$REQUEST_ID/approve" \
     -H "Authorization: Bearer $VENDORICA_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{ "scope": "all_gated_plus_selected",
           "resourceIds": ["8a1f…"],
           "ttlDays": 30,
           "reference": "SEC-1234" }'

   Every field is optional. Send {} for the standard grant with your organization’s default access period. ttlDays is 1 to 365.

2. Or reject, with a reason:

   curl -sS -X POST \
     "https://api.vendorica.com/v1/trust-center/access-requests/$REQUEST_ID/reject" \
     -H "Authorization: Bearer $VENDORICA_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{ "reason": "No active opportunity with this company", "reference": "SEC-1234" }'

   reason is required and stays inside your organization. The visitor is never told it, and is not told they were rejected: they see what a pending requester sees.

reference is up to 500 characters: a ticket key, or a ticket URL. It is shown next to the decision in the app (an https:// URL as a link) and recorded in the audit trail, so a reviewer can get from the decision back to the conversation behind it.

The visitor always gets the email

On approval Vendorica emails the access link to the address on the request. The link is never returned to you, and there is no option to skip the email. Your key lives in another system, and a working link to your gated documents does not belong in that system’s history.

The response carries request, visitorToken (expiry and status, no token) and emailSent. If emailSent is false the mail did not reach the provider. The approval still stands, and the visitor can have the link re-sent from your Trust Center page.

Retries and races: handle 409

A request can only be decided once. If someone decided it first (a person in the app, an auto-approval rule, or your own earlier call whose response you never received), the decision answers:

{
  "success": false,
  "error": "Access request has already been decided (status \"approved\")",
  "code": "ACCESS_REQUEST_ALREADY_DECIDED"
}

with status 409. Nothing was changed and no second link was minted, so retrying a timed-out approval is safe. On a 409, GET the request and sync your ticket with what it says (status, decidedVia, decisionReference). Do not parse the message. See Errors.

A 404 means the id is not a request in the key’s organization.

A Jira Automation setup

Jira Automation can do this without any code of your own. Two rules:

1. Create the ticket. A rule with the Incoming webhook trigger, whose URL you paste into a Vendorica webhook subscribed to trustcenter.access_requested. Add a Send web request action that calls GET /v1/trust-center/access-requests/{id} with the accessRequestId from the payload, then a Create issue action that writes the visitor’s details into the issue and keeps the request id in a field. If you are not on a plan with that webhook event, run a scheduled poller against ?status=pending instead.
2. Send the decision. A rule triggered when the issue moves to Approved or Rejected, with a Send web request action that calls …/approve or …/reject with the stored request id. Use the issue key as reference, and for a rejection, a field your reviewers fill in as reason.

Keep the API key in Jira’s secret storage rather than pasted into the rule, and treat a 409 response as “already decided”: fetch the request and comment on the issue instead of failing the rule.

What you will see afterwards

Your systems hear about the decision too. The trustcenter.access_approved and trustcenter.access_rejected webhooks carry decidedBy: reviewer for a person in the app, access_rule for an auto-approval or auto-deny rule, and api_client for a decision made through this API. A receiver can use api_client to recognise the echo of its own decision.

Trust the Trust Center operations in the reference over this page for field names: those are generated from the service, and this page is written by hand.