BenefitMyTrip API documentation

Scope and access

Free, manual US credit-card trip-delay guidance. No customer login, API key or OAuth token is required for these public routes. POST assessments require an anonymous session cookie and CSRF token. Administrator routes and the administrator OpenAPI endpoint are not part of this integration. There is no hosted MCP endpoint; a local MCP adapter is separate from this REST API.

Never request bank credentials, full card numbers, customer documents or personal identifiers. This integration uses non-saving assessments only.

1. Find the exact card

GET /cards returns an array of objects with id, name, issuer, network, variant, aliases, supported. Resolve the exact card identity with the traveler. The supported flag means published rules exist; it is not a coverage decision or a guarantee that rules apply on every date.

2. Retrieve the applicable guide

GET /cards/{id}/benefit?date=YYYY-MM-DD returns { "rule": … }. Use the incident date. A null rule means no applicable approved assessment rule is available. A rule includes its ID, status, card identity, source URL/title/hash/date and structured fields, including effective dates, verification date, limit/basis, threshold comparator, traveler definition, covered reasons, expenses and evidence.

Show the actual guide definitions before asking for confirmation. Do not infer that selecting a card confirms guide applicability, traveler eligibility or all policy terms.

3. Establish an anonymous CSRF session

GET /auth/csrf returns {"token":"…","headerName":"X-CSRF-TOKEN"} and sets a JSESSIONID cookie. Retain that cookie in memory and send it, together with the returned token in the named header, on the assessment POST. Use HTTPS and a server-side cookie jar. Keep sessions separate between users; do not borrow administrator sessions. Tokens and cookies must not appear in URLs or logs.

An expired or missing session/token can cause HTTP 403. Obtain a fresh anonymous session before retrying a non-saving request. Anonymous cookies are request-security state, not customer authentication. Cross-origin browser integrations should use a server-side adapter rather than assume browser CORS or cookie access is available.

4. Assess without saving

POST /assessments with Content-Type: application/json, session cookie, CSRF header and a JSON body. Always use save: false and omit the idempotency key or set it to null. The example below is a template: obtain a real catalog UUID, the incident date and actual traveler count from the user. Do not assume one traveler.

{
  "cardId": "REPLACE_WITH_EXACT_CATALOG_UUID",
  "incidentDate": "2026-09-19",
  "flight": null,
  "connection": null,
  "incident": "DELAY",
  "journey": "UNKNOWN",
  "delayHours": null,
  "overnight": "UNKNOWN",
  "payment": "UNKNOWN",
  "relationship": "UNKNOWN",
  "travelers": 1,
  "childAge": null,
  "relationshipConfirmed": "UNKNOWN",
  "reason": "UNKNOWN",
  "reasonSource": "UNKNOWN",
  "writtenEvidence": false,
  "guideConfirmed": "UNKNOWN",
  "commonCarrier": "UNKNOWN",
  "termsConfirmed": "UNKNOWN",
  "assistance": "UNKNOWN",
  "assistanceAmount": null,
  "save": false,
  "idempotencyKey": null,
  "purchasedInsurance": "UNKNOWN"
}

Download the complete request JSON Schema for required fields, enum values and bounds. This is a JSON Schema, not an OpenAPI document. The REST API does not apply the local MCP adapter’s defaults: send required UNKNOWN values explicitly. Incident date must be a real date today or earlier; this dynamic constraint is enforced by the server.

Unknown delay duration and child age can be null. Written evidence should be true only if confirmed; false means not established. Never map crew or general operational problems to equipment failure without evidence. Purchased insurance affects guidance only, not card eligibility.

Response and interpretation

The response contains id (null for a non-saving assessment), status, headline, evaluatedAt, rule, conditions, actions, evidence, cautions, carrierRequest, disclaimer. Conditions identify a key, state and explanation. Preserve the full result, sources and rule version in the agent’s explanation.

• NEEDS_REVIEW: unsupported card or no applicable approved rule.
• UNLIKELY_ELIGIBLE: a known material condition fails.
• NOT_YET_ELIGIBLE: the modeled time requirement is not met.
• POTENTIALLY_ELIGIBLE: qualifications or evidence remain unresolved.
• LIKELY_ELIGIBLE: modeled conditions are met; this is still not claim approval.

Potential limits are not approved payments or spending allowances. Do not multiply them by traveler count. Cancellation incidents cover only resulting delay-expense assessment, not cancellation-loss eligibility. The administrator and governing guide control. Link users to Claim help for evidence and filing guidance; this service never submits claims.

Errors, limits and privacy

Handle validation errors (400), unknown resources (404), CSRF failures (403), rate limits (429), and service errors without inventing eligibility. A 429 response includes Retry-After. The current beta allows up to 90 POST requests per minute per source address observed by the server; callers behind proxies may share that quota. This is not a guaranteed throughput allowance or availability commitment. Use bounded timeouts and backoff; do not automatically retry indefinitely.

Non-saving assessments are not inserted into the saved-assessment database. Infrastructure logs and the calling platform’s own retention policies are separate. Read our privacy policy and terms of use. Support: phanidileep4+benefitmytrip@gmail.com.