Environments and test mode

Maple runs two fully isolated environments, each with its own base URL and its own credentials:

Environment	Dashboard (developer console)	Base URL	Credential
Sandbox	https://app.staging.maple.inc	https://api.staging.maple.inc/v1	mpk_test_…
Production	https://app.maple.inc	https://api.maple.inc/v1	mpk_live_…

Develop and test in a sandbox Maple has prepared for your approved app. Invited members create their own sandbox keys through the developer console. App approval, location grants, and capability configuration remain Maple-managed.

Each dashboard reads and mutates only its own deployment. Follow the corresponding dashboard/invitation URL, sign in as needed, and check its environment badge and API base URL. Do not assume a cross-deployment session, shared app configuration, or automatic sandbox creation.

The two environments do not share credentials or operational data: a connection, subscription, or order in the sandbox is not the production resource.

Info

The API contract and signing format are shared, but each deployment needs its own approved app, credentials, grants, endpoints, and capability configuration. Changing the base URL is not production approval.

Why this matters

Use only the isolated test locations and supported workflows Maple has prepared for your integration. Verify the complete business workflow, signature handling, and diagnostics there before requesting production approval; a successful synthetic webhook is not certification.

flowchart LR
  subgraph Sandbox [Sandbox · api.staging.maple.inc]
    SK[mpk_test_ key] --> SD[(sandbox data)]
  end
  subgraph Production [Production · api.maple.inc]
    LK[mpk_live_ key] --> LD[(live data)]
  end

Telling environments apart in your code

The sandbox and production are separate deployments on different hosts, so a request or webhook belongs to whichever environment its host and credential do — you don’t infer it from the payload. Where you do want it explicitly:

• GET /v1/me returns the credential’s environment (test or live).
• The order resource carries livemode — true in production, false in the sandbox.

Warning

Use a separate webhook subscription per environment, and point each at the matching base URL. The delivered event doesn’t carry an environment field — the endpoint that receives it already tells you which environment it came from.

A test-first workflow

1. Build against the sandbox

   Point your client at https://api.staging.maple.inc/v1 with your mpk_test_… key. Connect to the sandbox location Maple grants you, subscribe a webhook, and exercise the full order loop.

2. Prove your webhook handler

   POST /v1/webhook_subscriptions/{id}/test delivers a signed webhook.test event so you can confirm signature verification and your 2xx response before any real order exists.

3. Get approved and go live

   Maple separately approves production access and prepares the app and location grants. Use the production dashboard to create an appropriately scoped mpk_live_… key, then use https://api.maple.inc/v1. Register a production webhook and complete the setup your integration needs, including an order-receiver connection for POS/order integrations. Do not assume sandbox grants, flags, or subscriptions carry over.

Going-live checklist

• Your client’s base URL and credential both point at the same environment.
• Your webhook handler verifies the HMAC signature and rejects bad or stale signatures. See Webhooks.
• You dedupe deliveries on the envelope id (delivery is at-least-once).
• You respond 2xx quickly and do slower work asynchronously.
• Decision calls are retried safely on transient errors (they’re replay-safe).
• You store the live signing secret (mwhsec_…) securely — it’s shown only once.