Skip to main content
The Partner API has one environment: production, at https://connect.laces.run/v1. There are no test keys and no sandbox. You build and test with the live keys from the Laces app, against your real organization.
Payments are real. A paid order charges a real mobile money account, and the money goes to your organization like any other sale. Test with free tickets where you can, use the smallest price you’re comfortable with otherwise, and refund afterwards. A full refund returns everything the buyer paid, the Laces fee included; your organization’s balance is debited only the ticket price.

Set up a test event

1

Create a private event

In the Laces app, create an event just for testing, for example “API test (do not register)”. Set its visibility to unlisted, so it never appears on laces.run’s public listings, and open registration.
2

Add cheap tickets

Add a free ticket type (a total of 0 confirms without any payment) and, if you need to test paid flows, one at a low price. If you sell by distance, add a distance so you exercise that part of the form too.
3

Check payments are enabled

Your organization must be cleared to take payments before any order or checkout session can be created, free ones included. Read the event over the API: payments_enabled: true means you’re ready; false means checkout is refused with payments_disabled. Contact Laces if it stays false.
The Partner API does list unlisted events: they belong to your organization. Make sure your site doesn’t show the test event to the public (filter it by event_id), and close or end it when you launch.

Test each flow

Every test order is a real order in your organization: it appears in your dashboard and in order reads, and the buyer email address you use receives a real confirmation. Use your own address, or one at a domain you control.

Local development

You can develop on your own machine with your live keys:
  • Server-side calls (token, events, orders, pay, session reads) work from anywhere. Keep the secret in a local .env file that is never committed.
  • Browser calls with the publishable key: add your dev server’s origin, for example http://localhost:3000, to Allowed domains. Only http://localhost:<port> and http://127.0.0.1:<port> are accepted over plain http, and the port is required. The app labels these “Local development domain: remove before launch”.
  • Hosted checkout and the embedded modal work end to end on http://localhost:<port> with your live keys. Add the origin to Return URL domains for the hosted return, and to Allowed domains for the page that opens the modal. A newly added domain can take up to 5 minutes to pass the browser’s CORS check.
  • Webhooks need a public https URL. Point a tunnel at your local receiver and register the tunnel URL; see Test your endpoint.

Use a separate key for development

Create a separate API key for development (for example “Club site (dev)”), with your local and staging origins, and a different one for your production site. Then you can regenerate or revoke the development key at any time without touching the live site, and remove local domains from the production key entirely.

Before launch

Work through Going live: remove local domains, point webhooks at your production server, and hide or close the test event.