The business using myne—your organisation in the product, and the tenant for every Connect route.
\nCall GET /v1/me first to learn your brand_id, then pass it in the path on other routes. API Credentials for the creating brand are scoped to that brand only. Other brands must Allow the same Client ID at /oauth/authorize.
GET /v1/me and GET …/brand return partner-safe brand fields. When the brand is in a Head office group, see Organisation (Head office group) on brand.organisation. Paths stay scoped to the authenticated brand — org fields are context only.
A Head office group of brands: one Head office brand and one or more venue brands that share customers and can run cross-venue offers.
\nWhere to see it: After auth, call GET /v1/me (read response.brand.organisation) or GET /v1/brands/{brand_id}/brand (same object on the brand in the response array). Solo brands return organisation: null.
Fields: - id / name — the organisation - role — venue or head_office for the brand you authenticated as - head_office_brand — parent Head office (id + name; same as this brand when role is head_office) - sibling_brands — peer venue brands (id + name; excludes this brand and the Head office)
Resource paths do not become organisation-scoped. Use these ids to understand relationships (for example Collect Across Venues stamp labels on evaluate venue_progress). Head office Collect Across Venues that target a child brand can appear on that child’s promotion catalog and redeem path for that type only.
A specific venue or site customers visit—how you split offers, links, and reporting by place.
\nUse location_id to scope customer browse, sync payloads, and promotion lists to one venue.
Someone you recognise with a full profile—usually a name and contact details you can message or segment.
\nCustomer IDs come from browse, sync, create/upsert, or your POS. Most loyalty and promotion calls need a customer id (or an external id you can resolve).
\nGET customer (by id or by external id) returns linked system ids in extended[], not a single top-level source/external_id. The profile includes pass id, Brand Points, and myne cashback. Visit totals sit on stats.
Spend or activity you can see before you have a full profile—or alongside one—when someone has not fully signed up.
\nCustomer browse returns visitors only when you set include_visitors=true. Otherwise results are known customers.
A B2B account (company or organisation) linked to contacts in myne.
\nThis is not the same as a location. A business may span multiple venues; a location is one physical site.
\nHow well you know someone on a profile:
\nFilter customer browse with the connection query parameter. This is about relationship state on the profile—not plan usage metering named “connections”.
A named audience of customers in myne. Paths use filter-groups; the partner-facing name is always customer group.
Membership can be maintained by dynamic refresh, scheduled refresh, import replace, or automation-driven changes.
\nLive offers also have a Claimed - {offer name} group. Treat it as a read segment: membership is added when a customer claims the offer on the join page. Connect can list the group and its members; it cannot add members or assign a claim.
\nConnect lists which customer groups exist, which customers are in one group, and which customer groups a single customer belongs to. Scope browse or search with customer_group_id.
A named audience of businesses (B2B accounts) in myne—the account-side counterpart to a Customer group.
\nMembership can use the same patterns as customer groups. Business groups are configured in the product; Connect Brands does not currently expose dedicated business-group list routes.
\nHow often someone tends to visit—New, Frequent, or Infrequent.
\nReturned on customer rows and available as a browse filter so you can tailor welcome paths vs loyalty depth.
\nA simple read on whether someone is active with your brand or drifting—useful for quick prioritisation on a profile.
\nReturned on customer profiles when myne has enough signal to classify them.
\nTimeline beyond the core customer or business fields: POS records, marketing activities, transactions, custom properties, and similar.
\nOn GET customer, extended[] is the identity list (source + external_id per connected system). The /customers/{id}/extended route is the activity timeline, not that identity list.
Stored value on a partner loyalty programme (for example Wrapped/Giftit or myne Cashback).
\nCredit endpoints read balance, ledger history, and add value. A customer may have no linked credit yet—in that case balance reads as zero and there is nothing to top up until credit is linked.
\nGET customer cashback is the internal cashback ledger for the brand, not a live Wrapped or Giftit credit GET. Use the credit endpoints when you need that partner programme's current balance.
Brand Points balance and earn/redeem history when Brand Points is enabled for the brand.
\nPoints endpoints mirror credit: balance, ledger, and top-up. Top-ups always need a reason for the staff ledger.
\nApple Wallet or Google Wallet identifiers tied to a customer's credit or rewards pass.
\nGET customer returns pass_id (the loyalty pass code) with points and cashback. Wallet serials are also returned alongside balance on the credit endpoint.
The main write path for pushing contacts, businesses, links, and extended metadata into myne.
\nSend up to 50 typed items per request. Prefer sync for bulk imports; use single customer upsert for one-off registrations. See external_id and external_data.
\nexternal_id is your identifier for a record (for example a CRM id or website user id). external_data is any extra attributes you choose to store on the core row.
Lookups and promotion evaluate/apply resolve that same external_id under your External source. GET customer lists every known source and id in extended[] rather than a single top-level pair. For extra partner metadata, also write extended rows under your source.
The integration key (source) that owns a customer or business external_id and extended fields.
Each API Credentials client has one source, derived from the app label in Integrations. GET …/me returns it as source.
Do not invent a source, and do not send source on write requests. Writes always stamp your credential’s source. Lookups default to your source.
An embedded myne CRM panel inside your own app.
\nMint a short-lived Bearer token from Connect, then load the widget for a specific customer or business.
\nClient ID and Client Secret for partner server-to-server access (formerly Custom API Basic).
\nCreate them in myne at API Credentials while signed in as a brand admin. Copy the Client Secret when it is shown—it cannot be retrieved later.
\nTwo uses, one Client ID: HTTP Basic or POST /v1/token with grant_type=client_credentials only reaches the creating brand. Other myne brands Allow the same Client ID in the browser (https://app.myne.network/oauth/authorize); that returns a code you exchange for tokens for that brand.
Resource calls accept Authorization: Basic … or Authorization: Bearer …. Access tokens last one hour; issuing another token does not cut earlier ones short. Authorization-code installs also return a refresh token. A brand can have more than one live refresh token for the same Client ID (for example two partner entities). Refreshing one does not invalidate the others. Revoke or rotate the secret stops them all.
An HTTPS destination myne POSTs when a subscribed brand event happens.
\nCreate subscriptions with Connect (/v1/brands/{brand_id}/webhooks) or in Settings → Webhooks → Outgoing. The signing secret is returned only on create and rotate. Partners only see destinations their Custom API app created. Poll collection GETs with updated_since when you prefer pull over push.
Topics include customer create/update, transactions, group membership, venue check-in, connection-form submit, and promotion redeem. The customer.created and customer.updated payloads include connection_type — connected when the customer has joined loyalty, known when myne has the customer but they have not joined, and unknown for an anonymous website visitor. It matches the connection_type on the customer list and get-customer endpoints.
HMAC-SHA256 of {unix_timestamp}.{rawBody} sent as X-Myne-Signature: t=<unix>,v1=<hex>.
Also send X-Myne-Topic and X-Myne-Delivery-Id. Verify with crypto.timingSafeEqual. Treat delivery_id as an idempotency key so retries are safe.
Optional ISO-8601 timestamp on collection list and search routes. When set, only rows whose watermark is on or after that instant (UTC, inclusive) are returned. Omit the parameter for today's full list.
\nMost collections use updated_at. Credit and points ledgers use created_at. Invalid timestamps return 400.
An offer set up in myne. It states what the customer gets, when it can be used, and where it can appear.
\nEach promotion can also say whether more than one offer may sit on the same order. Connect list, get, search, and evaluate responses include image_url (the offer image, or null).
Collect Across Venues (venue_unlock) is a passport offer: the same action at each selected site or Head office child brand unlocks a reward. On register/ordering evaluate (lsk/lso), progress is in venue_progress; incomplete passports use VENUE_UNLOCK_NOT_ELIGIBLE. Head office offers of this type that target a child brand are visible on that child’s Connect catalog and redeem path (this type only).
Some offers use Buy X Get Y rules. Evaluate promotions applies those on the open order.
\nA promotion mechanic: the customer must buy quantity X of matching items, then quantity Y of matching items is discounted (often free).
\nWhen buy (X) and get (Y) use the same products or categories, the paid X units are reserved first. Y does not cancel X. Example: Buy 1 Get 1 Free needs two matching units — pay for the first, discount the second. Buy 3 Get 1 Free needs four matching units.
\nWhen buy and get are different products or categories, the customer still needs enough X on the order, and the discount applies only to matching Y lines.
\nIf allow-repeat is on, each complete set of paid X plus discounted Y can apply again on the same order. Rolling Buy X Get Y can bank the buy side from earlier purchases in the period; then the current order only needs matching Y.
\nWhere the sale happens. Examples: a join page, an ordering app, a register, or an online store.
\nSend surface to match that place: lsk for register, lso for ordering. Use the same value on evaluate, apply, and complete. Those open-order calls always need surface — do not send integration_type there.
On browse, customer list, and search you may send integration_type instead as a coarse list filter when you only need which promotions can show (ordering, listing, or ecommerce) from customer Show vs available groups, without knowing which app will evaluate the sale. Some availability values are marketing only and are not used on evaluate, apply, or complete.
Two audience rules on a promotion:
\nA customer can see an offer and still be unable to use it until they meet the available rules.
\nA separate redeem rule is join-page claim. When an offer requires it, evaluate returns non_redeemable_cause.code CLAIM_REQUIRED until the customer has claimed on the join page. That is not assigned by this API.
The product id for a line on the open order (cart.items[].metadata.pos_id). It comes from the catalogue at the place you are selling. Example: the register item id at a POS.
We need this on each line so we can match the order to the promotion rules. It is not your Custom API customer or product id.
\nWhether more than one promotion can sit on the same open order at once.
\nEach promotion has its own allow-stacking setting in myne. If stacking is allowed, lock each reward with the same order id. One complete call then records all of them.
\nYour id for the open order. Use a POS order id, or generate a unique id. In the API this field is named basket_id.
We need the same id on evaluate, apply, and complete so we treat them as one order. If paid sales already go to myne, write that same id onto the order with the prefix MYNE so myne can match the payment. If you send Complete promotions after the customer pays, you do not write that mark.
\nA paid purchase stored in myne after the customer has paid.
\nBefore payment, the sale is an open order. Recording a promotion redemption does not create this purchase. The purchase is created when the POS or ordering system sends the sale.
\nA CRM timeline entry on a contact—manual notes and calls you log via Activities, plus other rows that appear in the staff activity feed.
\nThis is distinct from Customer events (POST …/events), which are integration-sourced timeline posts stamped with your External source.
A staff follow-up work item in myne—title, status, due date, assignees, and linked contacts or businesses.
\nConnect can list and search tasks. Creating tasks via Connect is not available yet.
\n| \n 1. Check what fits \n Ask which rewards fit this open order\n | \n → | \n\n 2. Take the money off \n You change the ticket in your POS\n | \n → | \n\n 3. Apply (lock the reward) \n Send Apply a promotion for this open order\n | \n → | \n\n 4. Mark the order \n Only if paid sales already go to myne\n | \n → | \n\n 5. Record the redemption \n When paid: myne records it, or you send Complete\n | \n
After step 1, myne tells you how to take money off for that place of sale:
\nThe promotion id is not a POS product id. Use it only when you Apply a promotion (step 3).
\n