Cresora Commerce Documentation

Hosted Payment Pages — Cresora-hosted checkout. PCI scope stays with Cresora + the gateway. The partner only handles the session redirect and the callback on completion.

ℹServer-to-server API

Run the examples on this page from your backend against the sandbox host. The API sends no CORS headers, so browser JavaScript cannot read its responses, and an API key must never be exposed in a browser. There is no interactive console here. Generating a client instead? Download the OpenAPI spec (YAML).

Create HPP session

POST/hpp/sessions

Authorization

BearerAuth

AuthorizationBearer <token>

Cresora API key, sent as an opaque bearer token in the Authorization header. Format:

csk_<prefix>_<random>

<prefix> — 8 URL-safe chars, shown in UI and logs for identification without revealing the full key (e.g. csk_Ab3kX9mQ…). Use ApiKey.prefix to match.
<random> — 24+ cryptographically random URL-safe chars.

Obtain via Partner Portal → Settings → API keys. Keys are only shown in full at creation/rotation time — Cresora does not retain the full value in retrievable form. Rotate any key that may have been exposed via logs, client code, or source control.

In: header

Header Parameters

Idempotency-Key*string

Client-generated unique key — a UUIDv4 is the recommended form. Cresora deduplicates within a 24-hour window scoped to the partner.

Format: 1–128 characters of letters, digits, . _ : -. Anything else is rejected with 400 validation_error. The character set is narrower than base64: padded base64 (+ / =) is NOT accepted, base64url is. The key is forwarded verbatim to the payment gateway on transaction creates, so it must satisfy the gateway's key contract too — rejecting locally gives you an actionable error instead of an opaque upstream failure mid-request.

Reserved prefixes — rejected with 400 idempotency_key_reserved:

hpp:, recurring: — Cresora's own server-minted deterministic keys. A client key in these namespaces could collide with a platform-generated record.
rb:, inv-charge:, inv-installment: — reserved by the payment gateway for its internally-minted keys.

Replay semantics:

Same key + same request body → Cresora returns the cached response from the original call. Response includes header X-Idempotent-Replay: true so the client can distinguish replays from fresh executions. Status code, body and side effects are identical to the original call.
Same key + different body → 422 idempotency_key_reused. Generate a new key and retry, or re-send the original body.
Key older than 24 hours → treated as a fresh key; no replay guarantee from beyond the window.

Retrying after an indeterminate failure. On 502 gateway_outcome_unknown the transaction is recorded as pending and the outcome is not yet known — retry with the SAME key (a fresh key risks a double charge) or poll the transaction. This is also what a gateway-side "an earlier request with this key is still in flight" response surfaces as.

Do NOT reuse keys across different partners. Scope is enforced per partner_id so the same key in partner A and partner B is independent.

Match^[A-Za-z0-9._:\-]+$

Length1 <= length <= 128

Request Body

application/json

TypeScript Definitions

Use the request body type in TypeScript.

merchant_id*string

Formatuuid

amount?string

REQUIRED (and positive) for a chargeable session. MUST be omitted — or sent as exactly "0.00" — when page_purpose=save_card: a save-card session performs a zero-dollar account verification, not a charge, and the gateway rejects a non-zero amount on it. A missing/zero amount on a chargeable session, or a positive amount on a save-card session, returns 400 validation_error with a field-level message.

Match^\d+\.\d{2}$

currency?"USD"

ISO 4217 currency code. Phase 1 supports USD only.

Value in

"USD"

expires_in_seconds?integer

Session TTL in seconds. Defaults to the platform-configured value (900s) when omitted; clamped to the vendor bounds.

Range60 <= value <= 900

rendering_mode?HppRenderingMode

Rendering surface for the HPP session.

redirect (default) — partner redirects the customer browser to hpp_url. Customer pays on the gateway-hosted page; on completion the browser is returned to the page's configured success-redirect destination. Completion is also delivered to the partner as an hpp.session.completed webhook event.
iframe — partner embeds the HPP in an <iframe> on their own page. Requires parent_origin; the gateway emits postMessage events back to the parent. Customer never leaves the partner's site.

Choice is per-session — same gateway-hosted page renders both surfaces; the difference is server-side activation of the postMessage event channel.

Value in

"redirect"
"iframe"

parent_origin?string

REQUIRED when rendering_mode=iframe. HTTPS origin string (scheme + host only, no path, no trailing slash), e.g. https://shop.example.com. The gateway uses this as the targetOrigin argument on every postMessage call.

Host MUST match an entry in the HPP page's configured AllowedEmbeddingDomains allow-list — session creation is rejected at the vendor side if it does not (fail-closed: an empty allow-list rejects every parent_origin). Matching is host-only; an explicit port on the origin is ignored.

Loopback origins (https://localhost[:port], 127.0.0.1, ::1) are rejected with parent_origin_unsafe: the gateway matches parent_origin against the page's allow-list and refuses a localhost allow-list entry, so such an origin can never match. For local development front the local app with a hostname that resolves to a public address (a dev subdomain or an HTTPS tunnel) and add that hostname to the allow-list.

Rejected when rendering_mode=redirect.

Match^https://[^/]+$

Lengthlength <= 256

allowed_embedding_domains?array<>

Per-session replica of the HPP page-level AllowedEmbeddingDomains allow-list. Hostnames (NOT URLs); wildcard subdomain prefix (*.example.com) allowed; raw IPs / no-TLD entries rejected, the literal localhost included (the gateway refuses it). Max 20 entries.

Cresora persists the list locally for audit replay. Vendor-side sync via the page-management API is pending vendor confirmation.

Itemsitems <= 20

tokenize?boolean

Request that the card be saved when this session's payment succeeds. On success Cresora vaults the credential and delivers the CRESORA saved-card reference to your hpp_session.completed webhook as data.cresoraVaultToken (a cvt_… value, also readable via the stored-credentials API). The raw gateway token is never delivered. true forces tokenization on for this session regardless of the merchant default.

tokenize saves the card; credential_usages is what makes it chargeable — and it is required alongside. A session that sets tokenize: true and declares no credential_usages (with no recurring_plan, whose plan implies recurring) is refused up front with 400 hpp_credential_usages_required, on card and ACH alike: the credential it would vault could never be charged — POST /transactions checks the requested use_type against the scope declared at save time, the scope is fixed at enrollment with no widen-afterwards path, and the gateway's own record of such a save has been observed to disagree with the empty scope (an unscheduled card-on-file consent the ISV never declared). Declare the intended uses on any session that saves a method.

If this payer saves a card that is already vaulted for the same customer under the same consent, the webhook carries the EXISTING cvt_… rather than a new one, and no stored_credential.vaulted event fires — nothing was created. Treat hpp_session.completed as the signal that a card is available to charge, and the cresoraVaultToken as an upsert key against your own customer record, not as proof of a first-time save.

Charging the saved card later is a SALE on POST /transactions: send the cvt_… value as vault_token with a use_type (raw PAN and raw gateway tokens are never accepted at that boundary).

A successful payment is NOT proof that the method was saved: the completion may carry no token (declined optional consent, or the gateway minted none) and the payment still succeeds with no error. Read tokenizationOutcome on the hpp_session.completed webhook (or tokenization_outcome on GET /hpp/sessions/{sessionId}) — vaulted vs not_vaulted.

Defaultfalse

page_purpose?string

The session's page purpose, and the ONLY spelling of the session intent — a save_card_only boolean that duplicated save_card was removed. payment (default) is a chargeable session.

save_card saves the payment method WITHOUT charging it: the gateway runs a zero-dollar account verification ($0 auth + AVS/CVV + immediate void), then vaults the method and captures consent ("save now, charge later"). Requires tokenize=true and amount omitted (or exactly "0.00"); incompatible with capture_mode: authorize (a $0 verification is not a hold).

save_card_with_initial_charge vaults the card AND charges the first payment of the inlined recurring_plan (required alongside): the completion materializes a CAPTURED sale for the plan's initial charge, the card is vaulted with recurring consent, and the GATEWAY creates the customer contract that originates the remaining payments. Requires tokenize=true and amount omitted (the charge is plan-driven); incompatible with capture_mode: authorize.

Rails. Cresora imposes no rail condition on any purpose — a session is never refused for the instrument mix its page offers. The gateway imposes one, on a single purpose: save_card_with_initial_charge requires a hosted page accepting CARD ONLY and refuses on any other, surfaced as 422 hpp_page_not_card_only. That constraint is on the PAGE's method set rather than the payer's instrument, so it applies even on a card+ACH page where the payer intends to pay by card. Every other purpose works on a page offering either rail or both.

Default"payment"

Value in

"payment"
"save_card"
"save_card_with_initial_charge"

recurring_plan?|

Inline recurring-schedule definition — REQUIRED with (and exclusive to) page_purpose: save_card_with_initial_charge. The plan is a definition the gateway builds the customer contract from; the follow-up charges are gateway-originated.

credential_usages?array<>

Permitted merchant-initiated uses of the stored credential, captured as cardholder consent at tokenization time. Requires tokenize=true. REQUIRED (at least one entry) whenever tokenize: true, unless a recurring_plan is present (the plan implies recurring); a tokenizing session declaring no usage is refused with 400 hpp_credential_usages_required, because the credential it would vault could never be charged — the scope is fixed at save time and cannot be widened afterwards. On a non-tokenizing session omit the field entirely. none is the ABSENCE of scope, so it is not a member of this enum.

More than one entry. Which combinations are accepted depends on whether the list names a plan-backed usage:

["unscheduled_cof", "one_time_future"] — the plan-less pair — is accepted on a CHARGING payment session with tokenize: true (vault-on-payment), whatever payment methods the hosted page offers: card, ACH, or both with the payer picking. One saved method then serves both a payer-present payment on the saved token (one_time_future, a cardholder-initiated use that is not consumed by one charge) and autopay (unscheduled_cof, merchant-initiated) without being saved twice. One route has NOT been shown to record the combined consent and is refused up front: the no-charge page_purpose: save_card session (422 multi_usage_requires_charging_session). Enroll the pair alongside a real payment instead.
A list naming recurring or installment alongside another usage is accepted ONLY on a page_purpose: save_card_with_initial_charge session. That is the one flow where the gateway establishes a single consent covering every declared reason; on any other page purpose it records no consent for such a mask, so Cresora refuses it up front (422 multi_usage_requires_recurring_plan) rather than vault a card against consent that was never captured.

On a save_card_with_initial_charge session recurring is implied by the plan and may be omitted. If you DO list usages there, the list must include recurring — the plan is the recurring agreement, so a list without it contradicts the session (422 credential_usage_contradicts_plan). Any additional usages are unioned with it.

Charging later: a MIT is authorized only for a reason inside the credential's declared scope (422 stored_credential_scope_violation), so a combined mask is what lets one saved card serve both a subscription and unscheduled merchant-initiated charges without saving it twice. The scope is fixed at enrollment: a method saved with one usage cannot gain a second later.

Itemsitems <= 4

capture_mode?string

How the hosted-page payment is captured. sale (default) — the payment is authorized and captured in one step; the completed session materializes a CAPTURED sale transaction (existing behaviour). authorize — the hosted page runs an authorization only; the completed session materializes an AUTHORIZED auth-only transaction that you capture later with a type: CAPTURE transaction on POST /transactions. Card rail only, and incompatible with a card-capture session (page_purpose: save_card / page_purpose: save_card_with_initial_charge).

Default"sale"

Value in

"sale"
"authorize"

amount_mode?string

How the hosted page treats the amount the payer sees. customer_entered (default) — the session sends no amount and the payer types it (historical behaviour; omitting the field is equivalent). suggested — the session's amount pre-fills the page but the payer may edit it (e.g. a suggested donation). locked — the session's amount pre-fills the page read-only and the gateway verifies on submit that the charged base (including supported fee components) matches the session amount (e.g. paying an invoice).

suggested and locked require a positive amount. Valid ONLY on the chargeable Payment flow — rejected with 400 on a save-card / card-capture session (page_purpose: save_card / page_purpose: save_card_with_initial_charge).

Default"customer_entered"

Value in

"customer_entered"
"suggested"
"locked"

customer_email_visibility?string

How the hosted page presents the payer email field on THIS session. Omit it (the default) to keep the page's own email setting. hidden — the field is not shown (typically a session that binds customer_id, whose email is already on file); optional — shown, may be left blank; required — shown and mandatory.

Two combinations are refused up front with 400: hidden with tokenize: true and no customer_id (the payer email is the gateway's customer anchor for a vaulted credential — bind a customer_id), and hidden together with a customer_email prefill (the hidden field rejects the prefill — omit one). Otherwise the choice is forwarded as requested; a value the merchant's email rule or the session type does not permit is refused by the gateway and surfaces as 422 validation_error (with errors[] naming customer_email_visibility where the gateway identifies the field): change the value, bind a customer_id, or omit the field.

Value in

"hidden"
"optional"
"required"

require_consent?|

Per-session override for whether the payer MUST tick the save-card consent box before the payment can be submitted. Tri-state:

omitted / null (default) — the gateway account-level consent setting applies (existing behaviour).
true — consent is mandatory: the hosted page blocks submission until the payer ticks the box. Use for flows that require an explicit card-on-file opt-in.
false — consent is optional: the box is shown but the payer may pay without ticking it. Declining completes a normal sale with no credential vaulted (data.cresoraVaultToken stays null) and no consent record written.

Requires tokenize=true (the consent box governs stored-credential capture; 400 otherwise).

Defaultnull

custom_fields?array<>

Merchant custom-field values (reconciliation identifiers — e.g. an invoice, tenant, or pay-by-link reference) carried onto the hosted page and, on completion, onto the materialized transaction. Each name must reference an ENABLED definition on the merchant; values are validated against the definition (400 custom_field_invalid otherwise). A definition VISIBLE on the hosted-payment-page surface pre-fills the page's field — a payer can edit a visible non-read-only field, and the gateway-confirmed values on the completion are authoritative over the submitted ones. A definition HIDDEN on that surface is accepted too: its value is applied to the resulting transaction server-side, exactly as supplied, without being rendered to the payer — the gateway validates it at session create, and a value it refuses is rejected with 422 validation_error whose errors[] names your custom_fields entry (gateway_rejected). Echoed on the materialized transaction's custom_fields and on the hpp_session.completed webhook.

Rejected with 422 custom_field_invalid when page_purpose is save_card: the hosted page does not render custom fields on save-card pages, so the values would be silently discarded.

Itemsitems <= 10

customer_email?string

Optional customer email pre-filled onto the hosted page. Strongly recommended when tokenize=true: the gateway vaults a saved card against a Customer record built from this email, so supplying it guarantees the card-on-file token is minted even if the payer leaves the (optional) email field blank. Also used for the payment receipt.

Formatemail

Lengthlength <= 254

customer_id?string

Optional CRESORA customer id (the id returned by POST /merchants/{merchant_id}/customers) binding this session to exactly one directory customer. When supplied, tokenization / consent capture resolves against THAT customer exclusively — no fallback to the email-derived find-or-create. Cresora resolves the gateway-side identity internally; gateway ids are never accepted or exposed on this surface.

The id is validated at session create: it must exist under this merchant, else the create is rejected with not_found (HTTP 404 — no cross-merchant binding). A gateway-side rejection of the resolved identity surfaces as hpp_customer_rejected (HTTP 422, retryable=false). This is NOT your own CRM reference — for free-form reconciliation identifiers use custom_fields. Omit for the default behaviour (customer derived from the cardholder email).

Formatuuid

level3_data?

Level 3 payload for the session's eventual transaction. The gateway stores it on the session and re-stamps it server-side on page submit (the payer's browser cannot tamper with it). Persisted on the session — echoed on GET /hpp/sessions/{sessionId} and attached to the materialized transaction on completion. Not accepted on save-card-only sessions (400 level3_not_supported_for_save_card_only). No level2_data on this surface: Level 2 on hosted-page flows comes from the merchant-level order-data defaults.

allowed_payment_methods?array<>

Optional per-session NARROWING of the payment methods the hosted page renders — the page shows the intersection of this list with its own configured methods. Use it to pin one rail of a card+ACH page for a single session (e.g. ["ach"] for a rent payment on a page that also takes cards). Omit the field for no restriction: the page renders its full configured set (existing behaviour).

This is a RESTRICTION, not a rail declaration — on a session restricted to several methods the payer still picks, and the settled payment_method is reported on completion exactly as before. A restriction that excludes EVERY method the merchant's page offers is rejected up front with 422 hpp_rail_restriction_not_offered (the page would render no payment methods at all); a partial overlap is accepted and the page renders the surviving methods. An empty list is rejected with 400 — omit the field instead.

Items1 <= items <= 2

Response Body

`application/json`

`application/problem+json`

curl -X POST "https://example.com/hpp/sessions" \  -H "Idempotency-Key: string" \  -H "Content-Type: application/json" \  -d '{    "merchant_id": "500924a8-3f5e-4c00-beb8-2efcde988aea"  }'

{  "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08",  "merchant_id": "500924a8-3f5e-4c00-beb8-2efcde988aea",  "payment_method": "card",  "state": "PENDING",  "hpp_url": "http://example.com",  "iframe_url": "http://example.com",  "rendering_mode": "redirect",  "capture_mode": "sale",  "amount_mode": "customer_entered",  "page_purpose": "payment",  "recurring_plan": {    "recurring_amount": "string",    "frequency": "daily",    "interval": 1,    "number_of_payments": 2,    "initial_charge_amount": "string"  },  "customer_id": "160c0c4b-9966-4dc1-a916-8407eb10d74e",  "amount": "string",  "surcharge_amount": "string",  "convenience_fee_amount": "string",  "total_amount": "string",  "currency": "USD",  "expires_at": "2019-08-24T14:15:22Z",  "created_at": "2019-08-24T14:15:22Z"}

Get HPP session status

GET/hpp/sessions/{sessionId}

Authorization

BearerAuth

AuthorizationBearer <token>

Cresora API key, sent as an opaque bearer token in the Authorization header. Format:

csk_<prefix>_<random>

<prefix> — 8 URL-safe chars, shown in UI and logs for identification without revealing the full key (e.g. csk_Ab3kX9mQ…). Use ApiKey.prefix to match.
<random> — 24+ cryptographically random URL-safe chars.

In: header

Path Parameters

sessionId*string

Formatuuid

Response Body

`application/json`

`application/problem+json`

curl -X GET "https://example.com/hpp/sessions/497f6eca-6276-4993-bfeb-53cbbbba6f08"

{  "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08",  "state": "PENDING",  "payment_method": "card",  "capture_mode": "sale",  "amount_mode": "customer_entered",  "page_purpose": "payment",  "recurring_plan": {    "recurring_amount": "string",    "frequency": "daily",    "interval": 1,    "number_of_payments": 2,    "initial_charge_amount": "string"  },  "customer_id": "160c0c4b-9966-4dc1-a916-8407eb10d74e",  "tokenization_outcome": "not_requested",  "vault_token": "string",  "transaction_id": "0fec1e58-b197-4052-99cf-2218496c5482",  "completed_at": "2019-08-24T14:15:22Z",  "expires_at": "2019-08-24T14:15:22Z",  "rendering_mode": "redirect",  "last_attempt": {    "at": "2019-08-24T14:15:22Z",    "reason": "reversed"  },  "card": {    "last4": "string",    "expiry_month": 1,    "expiry_year": 0,    "brand": "string"  },  "bank": {    "account_type": "CHECKING",    "account_last4": "string",    "routing_last4": "string"  },  "token_capture_failure": {    "at": "2019-08-24T14:15:22Z",    "reason": "string"  },  "level3_data": {    "ship_from_zip": "string",    "destination_zip": "string",    "destination_country_code": "string",    "invoice_number": "string",    "order_number": "string",    "duty_amount": "string",    "freight_amount": "string",    "discount_amount": "string",    "line_items": [      {        "product_code": "string",        "commodity_code": "string",        "description": "string",        "upc": "string",        "invoice_number": "string",        "tax_type": "string",        "quantity": "string",        "unit_of_measure": "string",        "unit_price": "string",        "discount_amount": "string",        "total_amount": "string",        "tax_amount": "string",        "tax_rate": "string",        "extended_amount": "string",        "freight_amount": "string",        "duty_amount": "string",        "tax_included": true      }    ]  }}

Cancel HPP session

POST/hpp/sessions/{sessionId}/cancel

Authorization

BearerAuth

AuthorizationBearer <token>

Cresora API key, sent as an opaque bearer token in the Authorization header. Format:

csk_<prefix>_<random>

<prefix> — 8 URL-safe chars, shown in UI and logs for identification without revealing the full key (e.g. csk_Ab3kX9mQ…). Use ApiKey.prefix to match.
<random> — 24+ cryptographically random URL-safe chars.

In: header

Path Parameters

sessionId*string

Formatuuid

Header Parameters

Idempotency-Key*string

Client-generated unique key — a UUIDv4 is the recommended form. Cresora deduplicates within a 24-hour window scoped to the partner.

Reserved prefixes — rejected with 400 idempotency_key_reserved:

hpp:, recurring: — Cresora's own server-minted deterministic keys. A client key in these namespaces could collide with a platform-generated record.
rb:, inv-charge:, inv-installment: — reserved by the payment gateway for its internally-minted keys.

Replay semantics:

Same key + same request body → Cresora returns the cached response from the original call. Response includes header X-Idempotent-Replay: true so the client can distinguish replays from fresh executions. Status code, body and side effects are identical to the original call.
Same key + different body → 422 idempotency_key_reused. Generate a new key and retry, or re-send the original body.
Key older than 24 hours → treated as a fresh key; no replay guarantee from beyond the window.

Do NOT reuse keys across different partners. Scope is enforced per partner_id so the same key in partner A and partner B is independent.

Match^[A-Za-z0-9._:\-]+$

Length1 <= length <= 128

Response Body

`application/json`

`application/problem+json`

curl -X POST "https://example.com/hpp/sessions/497f6eca-6276-4993-bfeb-53cbbbba6f08/cancel" \  -H "Idempotency-Key: string"

{  "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08",  "state": "PENDING",  "payment_method": "card",  "capture_mode": "sale",  "amount_mode": "customer_entered",  "page_purpose": "payment",  "recurring_plan": {    "recurring_amount": "string",    "frequency": "daily",    "interval": 1,    "number_of_payments": 2,    "initial_charge_amount": "string"  },  "customer_id": "160c0c4b-9966-4dc1-a916-8407eb10d74e",  "tokenization_outcome": "not_requested",  "vault_token": "string",  "transaction_id": "0fec1e58-b197-4052-99cf-2218496c5482",  "completed_at": "2019-08-24T14:15:22Z",  "expires_at": "2019-08-24T14:15:22Z",  "rendering_mode": "redirect",  "last_attempt": {    "at": "2019-08-24T14:15:22Z",    "reason": "reversed"  },  "card": {    "last4": "string",    "expiry_month": 1,    "expiry_year": 0,    "brand": "string"  },  "bank": {    "account_type": "CHECKING",    "account_last4": "string",    "routing_last4": "string"  },  "token_capture_failure": {    "at": "2019-08-24T14:15:22Z",    "reason": "string"  },  "level3_data": {    "ship_from_zip": "string",    "destination_zip": "string",    "destination_country_code": "string",    "invoice_number": "string",    "order_number": "string",    "duty_amount": "string",    "freight_amount": "string",    "discount_amount": "string",    "line_items": [      {        "product_code": "string",        "commodity_code": "string",        "description": "string",        "upc": "string",        "invoice_number": "string",        "tax_type": "string",        "quantity": "string",        "unit_of_measure": "string",        "unit_price": "string",        "discount_amount": "string",        "total_amount": "string",        "tax_amount": "string",        "tax_rate": "string",        "extended_amount": "string",        "freight_amount": "string",        "duty_amount": "string",        "tax_included": true      }    ]  }}

H P P

200application/json

400application/problem+json

401application/problem+json

403application/problem+json

404application/problem+json

409application/problem+json

422application/problem+json

429application/problem+json

500application/problem+json

502application/problem+json

503application/problem+json

504application/problem+json

200application/json

401application/problem+json

403application/problem+json

404application/problem+json

429application/problem+json

500application/problem+json

200application/json

400application/problem+json

401application/problem+json

403application/problem+json

404application/problem+json

409application/problem+json

422application/problem+json

429application/problem+json

500application/problem+json

502application/problem+json

503application/problem+json

504application/problem+json

`application/json`

`application/problem+json`

`application/problem+json`

`application/problem+json`

`application/problem+json`

`application/problem+json`

`application/problem+json`

`application/problem+json`

`application/problem+json`

`application/problem+json`

`application/problem+json`

`application/problem+json`

`application/json`

`application/problem+json`

`application/problem+json`

`application/problem+json`

`application/problem+json`

`application/problem+json`

`application/json`

`application/problem+json`

`application/problem+json`

`application/problem+json`

`application/problem+json`

`application/problem+json`

`application/problem+json`

`application/problem+json`

`application/problem+json`

`application/problem+json`

`application/problem+json`

`application/problem+json`