Verify your deployment

Prove Paylode is actually live and reachable from your integration — in under five minutes, with nothing but your browser and one API call.

Whether you embedded a perks page, pointed at a hosted page, or built against the API, the same two checks confirm it's working: the browser tells you the requests are firing and succeeding, and a health call confirms you're reaching Paylode over the network. If both pass, your integration is talking to the platform correctly.

Before you begin

• A page or a shell. For an embed or hosted page, open the page where Paylode should appear. For an API integration, any terminal or a browser console is enough.
• Your host. The API host for the operation you're calling — see Platform basics. The examples below use the perk collections host.

Check 1: Watch the requests in the browser

For an embedded or hosted surface, the browser's developer tools show you exactly what's happening.

1. Open your page and open the browser's developer tools (the Network panel).
2. Reload the page and watch the requests to *.paylode.com.
3. Confirm each one returns a 200 (or another success status). A 200 means the request reached Paylode and came back with content.

What the common statuses mean:

Status	Meaning
200	Success — the request worked.
301	Redirect — usually a .tech host forwarding to .com. Update the URL.
401	Auth failed — the API key is missing or wrong (see Authentication).
403	Reached us, but not allowed for this key.
404	Wrong path, or an id that doesn't belong to your account.
5xx	A server-side error — retry, and if it persists, capture the request and contact support.

Check 2: Smoke-test the API

Every Paylode API exposes a public version endpoint that needs no API key. It's the simplest possible proof that you can reach a host over the network:

curl https://perk-collections.paylode.com/version

{ "version": "1.0.0" }

A 200 with a version body means DNS, TLS, and routing to that host all work. If this succeeds but an authenticated call fails, the problem is your key or the specific operation — not connectivity. See getVersion on the developer site.

Log any non-200 in your own integration

Drop this wrapper around your fetches during rollout so a bad status shows up in your logs instead of failing silently:

async function paylodeFetch(url, options) {
  const res = await fetch(url, options);
  if (!res.ok) {
    console.error(
      `[paylode] ${res.status} ${res.statusText} for ${url}`
    );
  }
  return res;
}

// e.g.
await paylodeFetch("https://perk-collections.paylode.com/version");

Hand this to a developer

If you're a product manager confirming a rollout, forward this to whoever owns the page:

Please open the page in a browser with the Network panel open, reload, and confirm every request to *.paylode.com returns 200. Then run curl https://perk-collections.paylode.com/version and confirm it returns a version number. If anything returns 401/403, it's an API-key issue; if you see 301, we're pointing at an old .tech host and should switch to .com.

Troubleshooting

caution

Requests don't appear at all. If no *.paylode.com requests show up in the Network panel, the integration isn't running on the page. For an embed, confirm the loader script and its container are both present (see Embed a perks page). A strict Content-Security-Policy on your page can also block the requests before they fire — check the browser console for CSP errors.

note

A 301 on every call. You're calling a legacy *.paylode.tech host. It'll redirect, but update your configuration to the *.paylode.com equivalent — see Platform basics.

note

200 on /version but 401 everywhere else. Connectivity is fine; authentication isn't. Recheck the X-API-Key header on your authenticated calls — Authentication covers the exact format.