Skip to main content
POST
Token Replacement in Request API

Token Replacement Guide

Replace tokens with card data in API requests
This is PCI Booking’s core proxy feature. Instead of processing payments through PCI Booking’s gateway integrations, you send the exact API request your third-party system expects, with token placeholders where card data should go. PCI Booking swaps in the real card data and forwards the request transparently, so the third party receives a normal API call with real card details while you never handle sensitive data.

Error Responses

Error detail

Each condition below gives the exact moreInfo text, why it happens and how to resolve it. The full set is on the Error Handling page.
HTTP status: 400message: Bad input datamoreInfo: the wording depends on which endpoint you called:
The first is returned by token replacement in a request (paycard/relay). The second is returned by tokenization on response (paycard/capture). They mean the same thing.Reason. The profileName you passed could not be resolved for the account making the request. In almost every case the profile does exist, but on a different account than the one your credentials belong to. A misspelled profile name produces the same error.How to resolve.A PCI Shield profile belongs to the account, not to the sub-user that calls the API. When a sub-user makes a request, the profile is looked up against that sub-user’s parent account. A profile configured on one account is never visible to a sub-user of a different account, and sandbox and production accounts are separate.To check which profiles your credential can see:
  1. Identify the parent account of the sub-user whose credentials you are using.
  2. Sign in to the PCI Booking portal as that account and open PCI Shield Settings > PCI Shield Profile Settings.
  3. Confirm the profile name appears there, spelled exactly as you send it. Profile names are matched exactly.
  4. If the profile is listed under a different account, switch your request to a sub-user of that account rather than copying the profile.
There is no API endpoint that lists the profiles on your own account. GET /api/booker returns the platform-wide preset tokenization profiles, which are a different set. Your own profiles are visible in the portal only.
See also: Content Filters, Target Profiles
HTTP status: 400message: Bad input datamoreInfo:
Reason. The body parsed, but the profile’s selectors did not match anything in it, so no card data was substituted. The request was not relayed. This is a mismatch between the profile and the payload, not a problem with the token.How to resolve.
  1. Compare the profile’s selectors against the exact payload you sent. A selector that assumes a different nesting depth or element name matches nothing.
  2. Check the namespaces. For XML and SOAP, a selector written without namespace handling will not match a namespaced document.
  3. Confirm the body is the format the profile was written for. A profile written for XML will not match a JSON body.
  4. Test the profile against a saved copy of a real request before using it in production.
See also: Content Filters
HTTP status: 400message: Bad input datamoreInfo:
Reason. Token replacement had nothing to work on. The body of the request you asked to be relayed was empty, so there was no content in which to substitute card data.How to resolve.
  1. Send the third-party request you want relayed as the body of the call, not as a query parameter.
  2. If you are pointing at the content with a parameter name, check that parameter is present and actually carries the payload.
  3. Check no proxy or client library between you and the API is dropping the body on a GET relay.
HTTP status: 400message: Bad input datamoreInfo:
Reason. Token replacement needs to know how to parse the body before it can find the placeholders. Without a Content-Type header it cannot choose a parser.How to resolve.
  1. Set Content-Type to match the body you are sending, for example application/json, text/xml, or application/x-www-form-urlencoded.
  2. Send the charset if the third party requires one, for example text/xml; charset=UTF-8.
HTTP status: 400message: Bad input datamoreInfo:
Reason. The httpMethod parameter names a method the relay does not forward.How to resolve.
  1. Use one of POST, GET, PUT, PATCH or DELETE, in upper case.
  2. Omit the parameter to accept the default of POST.
HTTP status: 400message: Bad input datamoreInfo:
Reason. The targetUri could not be parsed as an absolute URL, so the relay had nowhere to send the request.How to resolve.
  1. Send an absolute URL including the scheme, for example https://api.example.com/path.
  2. URL-encode the value if you pass it as a query parameter, so that its own query string does not terminate yours.
HTTP status: 400message: Bad input datamoreInfo:
Reason. The relay was told to take the token from the X-pciBooking-cardUri header, but the header was absent or held no readable token.How to resolve.
  1. Add the X-pciBooking-cardUri header carrying the full token URI.
  2. Separate multiple tokens as the endpoint documents, and check none of them is empty.
HTTP status: 504message: Request timed outmoreInfo: not populated for this condition. The code and the endpoint are the only signal.Reason. PCI Booking relayed your request but the target server did not answer within the timeout. The failure is on the far side, not in PCI Booking. Card data may already have reached the third party, so the operation cannot be assumed not to have happened.How to resolve.
  1. Check how long the third party takes to respond. The complete round trip must finish within 29 seconds, so raising timeout beyond that does not help. If the third party regularly needs longer, contact support@pcibooking.net for an alternative setup.
  2. Confirm the target host is reachable and not rate limiting or blocking the call. PCI Booking calls the third party from its own addresses, which the third party may need to allow.
  3. Do not blind retry a charge. Query the third party for the outcome first. A timeout is an unknown result, not a failure.
See also: Outbound IPs
HTTP status: 401message: You are not authorized to access this resource. Please contact customer support.moreInfo: one of the following, depending on which check failed:
Reason. The credential authenticated fine, but it cannot act on the token in the request. Either the token does not exist or it is not yours to use. The generic wording makes this the single most misread error in the API. On a token call it is far more often one of the causes below than an actual permissions problem.How to resolve.
  1. Check the token still exists. This is the most common cause. On every token endpoint except Delete Token, a token that does not exist or was deleted returns this error, the same as a token that belongs to another account. See Token Not Found or Not Accessible.
  2. Check the tokenization actually succeeded. If the call that should have created the token failed, the token never existed, and calls that use it report -1003.
  3. Check the environment. A sandbox token cannot be used from production, or the reverse.
  4. Check ownership and association. See the rules below.
Ownership and association.A token is owned by the account that created it. Another account can use the token only if the token was explicitly associated with it:
  • At tokenization, by passing merchantId on the tokenizing call.
  • After tokenization, by associating the token with the merchant.
Two rules catch people out:
  • An association can only target a primary account. If you pass the ID of a sub-user or a secondary property, the request is rejected and you must associate the token with the parent account instead.
  • Tokens never cross environments. A token created in sandbox cannot be used from production, and the reverse is also true.
Account level blocks.An account that has exceeded its processing allowance is blocked, and every billable API call from it then fails with HTTP 403 and code -1003, even though the credentials are still valid and can still sign in to the portal. In this response message is empty (null) and moreInfo holds only the generic -1003 text, so nothing in the body explains the block. The 403 status is what tells it apart from a token that is not accessible, which returns 401.This is a common cause on sandbox accounts, which have a lower allowance than production.Check for it when a 403 with -1003 appears suddenly across calls that used to work, on more than one token. A block affects every billable call on the account at once, whereas a genuine ownership problem affects only the specific token. Contact support with your account name to have the allowance reviewed and the block lifted.

Parameter Constraints

  • cardToken must contain a valid card URI with a 32-hex token.
  • targetUri is required.
  • httpMethod defaults to POST. Accepted values: POST, GET, PUT, PATCH, DELETE.
  • postResponseAction accepts ClearCVV or DeleteToken.
All URLs must be HTTPS. URL-encode all query string components.

Parameters

Authentication

This is a browser-facing endpoint. Use one of the authentication methods below instead of the API key shown above.
string
Recommended. A long-lived token for browser-side calls. How to generate.
string
Alternative. Valid for 5 minutes. How to generate.
If both are provided, the session token takes precedence.

Query String

string
required
The token URI identifying the card in PCI Booking.
string
required
The HTTPS URL of the third party to relay the request to.
string
default:"POST"
The HTTP method to use when calling the target URI. One of: POST, GET, PUT, PATCH, DELETE.
string
The ID of a target profile configured for this request. If omitted, PCI Booking uses placeholder-based replacement instead. See Choosing a Replacement Mode.
string
For placeholder-based replacement: the name of the one parameter that contains the placeholders. PCI Booking looks for it first in the query string of targetUri, then in the form body. Ignored if profileName is provided. If omitted, PCI Booking searches the whole request body for placeholders.
string
Action to perform after a successful relay. ClearCVV clears the CVV from the token. DeleteToken deletes the token entirely. If omitted, no action is taken.
int
Seconds to wait for the third-party response before timing out. Default 60. The complete round trip must still finish within 29 seconds; see Timeouts.

Headers

string
Compression format: gzip or deflate. Omit if no compression is needed.

Request Body

The request body and headers are relayed to the third party as you send them, with card data inserted. Call this endpoint with POST; the third party receives the method set in httpMethod. Structure the request as the third party’s API requires, including any headers it needs. See What PCI Booking Changes in Your Request. Mark where card data goes with placeholders such as $~Number~$, or reference a target profile with profileName, as in the second example below.

Request Example

Send a JSON payment request to a third-party API, with PCI Booking replacing the card placeholders with real data before forwarding. You authenticate to PCI Booking with the accessToken query parameter. Any Authorization header you send belongs to the third party and is forwarded to it. The body is written as text so that the expiration month and year can be sent as JSON numbers, with their placeholders outside quotes. See Placeholders in JSON.
PCI Booking replaces the $~Number~$, $~ExpirationM~$, $~ExpirationYYYY~$, $~CVV~$ and $~OwnerName~$ placeholders with the card data from the token before forwarding the request to api.thirdparty.com. See the full placeholder list. To use a target profile (pre-configured replacement rules) instead of placeholders, send the card fields the profile targets with empty values. PCI Booking fills them in:

Response

200 - The third-party response, relayed back as-is.
Consider adding business logic based on the CVV retention policy status after a token replacement request.