Log in
Start for free
Start for free

Developer & API Terms

Rules for building against the LetBuyy APIs, webhooks, and themes.

Applies to
Developers
Clauses
7
Reading time
3 min
Revised
3 August 2026

These policies are published for review and are not yet in force. LetBuyy has not opened to merchants, so no agreement has been formed with anyone. They take effect on the day the platform launches, and the effective date will be stated here. Last revised 3 August 2026.

In short

  • You may build integrations against LetBuyy for a merchant who has authorised you.
  • API credentials are tied to a specific store. Using one to reach a different store is a breach, not a bug to exploit.
  • Webhooks are signed. Verify the signature before you trust the payload — an unverified webhook endpoint is an open door.

This summary is written to be understood. The clauses below are what actually applies — where the two differ, the clauses govern.

  1. Getting access

    API access is granted per store, by the merchant who owns that store. Credentials carry the scopes the merchant approved and nothing more.

    The developer portal is currently closed to new public app registrations. Existing integrations continue to work; new ones are onboarded case by case.

  2. Credentials

    Treat API keys and secrets as you would a password. Do not commit them, do not ship them in client-side code, and do not share them between merchants.

    If a credential leaks, rotate it immediately and tell us. We would rather hear it from you.

    We may revoke a credential without notice if we see it being used from an unexpected pattern that suggests compromise.

  3. Store isolation

    Every record on LetBuyy belongs to exactly one store, and that boundary is enforced in the database, not just in application code.

    Deliberately probing for cross-store access is a breach of these terms and, depending on what you reach, an offence under the Information Technology Act.

    If you find a way across that boundary, report it rather than using it. We will not pursue a good-faith reporter who stops at proof and tells us promptly.

  4. Webhooks

    Webhook payloads are signed with a shared secret. Verify the signature on every delivery using a constant-time comparison before acting on the contents.

    Deliveries may arrive more than once. Make your handler idempotent — key on the event id, not on the fact that a request arrived.

    Endpoints that fail repeatedly are backed off and eventually disabled. Delivery records are retained for 90 days, which is your window to reconcile a gap.

    NoteAn endpoint that skips signature verification will accept anything anyone sends it. This is the single most common integration vulnerability we see.

  5. Rate limits and fair use

    The APIs are rate limited. Handle a 429 by backing off, not by retrying immediately from more workers.

    Do not poll for changes you could receive as a webhook. Polling at high frequency across many stores is the fastest way to get throttled.

  6. Merchant and shopper data

    Data you reach through the API belongs to the merchant, and often describes their customers. You may use it only to provide the function the merchant installed you for.

    You may not build a profile of shoppers across merchants, sell derived data, or retain data after the merchant uninstalls you beyond what law requires.

    If you process personal data on a merchant's behalf, you are their processor and the obligations in the Data Processing Addendum apply to you too.

  7. Themes

    Theme templates are rendered through a sanitiser that escapes output and blocks a fixed list of dangerous constructs. Do not attempt to defeat it.

    A theme must not load third-party scripts that were not disclosed at review, collect shopper input beyond what the storefront needs, or alter checkout behaviour.

Questions about this document

Write to support@letbuyy.com and quote the clause number. For a complaint rather than a question, use the grievance process.