Developer and API Terms
Document
PACK & KIN STUDIO — DEVELOPER AND API TERMS
Version: 1.0 · Status: Approved · Approved: 2026-09-07 · Approved by: Dax Barron, Mail and More LLC
Approved by the operator for publication. A published version is immutable; a correction is issued as a new version rather than an edit.
1. Who this is for
These Developer and API Terms (these "Terms") are between Mail and More LLC, an Arizona limited liability company ("Pack & Kin," "we," "us") and the person or entity that registers as a developer ("Developer," "you").
They govern your use of the Pack & Kin API, SDKs, webhooks, developer documentation and the partner portal (together, the "Developer Services"), and what you may do inside a store that has authorized you.
You own no store. A developer is a distinct party on this platform — you are not a store, not a dealer, and not our agent. Your entire reach into a store comes from that store's authorization, and Section 3 is the most important section here.
Incorporated by reference: the Acceptable Use Policy (/legal/acceptable-use/) and the
Privacy Notice (/legal/privacy/).
If you also operate a store, that store is governed by the Platform Terms of Service, separately.
2. Registration and acceptance
2.1 You must register a developer account, provide accurate information about yourself and your organization, and keep it current. We may approve, decline or revoke a registration at our discretion.
2.2 A human accepts these Terms. A machine credential cannot agree to anything. These Terms are accepted by an authorized person through the partner portal, and your continued use of a credential is subject to a current acceptance by such a person. If we publish a materially changed version, we may require re-acceptance before your credentials continue to work.
2.3 You are responsible for everyone who acts under your developer account, and for keeping the list of people with access current.
2.4 Eligibility. You must be able to form a binding contract, must not be on a U.S. sanctions or denied-party list, and must not be a person we have previously terminated.
3. The store's authorization — the whole basis of your access
3.1 What it is. A store grants you a standing authorization naming you, the store, and the exact scopes the store consented to. It is created by a store administrator on the store's own consent screen. Without it you have no access to that store, and nothing else creates one — not a credential we issue you, not a relationship with a dealer, and not the store's staff telling you it is fine.
3.2 One authorization per store. You hold at most one standing authorization per store. Re-consenting replaces the scopes on it rather than adding a second authorization. You will not attempt to accumulate overlapping authorizations, and you will not treat the union of a past and a present consent as your permission.
3.3 It is the store's, not yours. The store decides what to grant, may change it, and may revoke it at any time, for any reason, without notice to you. You have no right to a continued authorization, and revocation is not a breach by anyone.
3.4 Revocation takes effect immediately. Authorization status is checked on every credentialed request. A revoked authorization stops your next call — it does not wait for an access token to expire. You will design your integration to handle a revocation cleanly at any moment, including mid-workflow, and you will not retry around it, re-authenticate around it, or present it to the store as an error on our side.
3.5 You may not ask for more than you need. You will request the narrowest scopes your integration actually requires, and you will explain to the store, in plain language, what you will do with each. You will not request a scope in order to hold it in reserve.
3.6 What a scope permits. A scope is a permission to act, not a promise of data. What a credential can actually do is the intersection of: what the store granted you; the scopes your client is registered for; any ceiling we apply; and what the current API catalog supports. Any of these can narrow without notice, and your integration must handle a reduced or refused permission gracefully. A grant that is broader than the intersection does not entitle you to the difference.
3.7 Acting only for the store. You will use an authorization only to provide your integration to that store, and only for the purposes you described to it. You will not use one store's authorization to act for, or to obtain data about, another store.
4. Credentials
4.1 Yours to protect. API keys, client secrets and tokens are issued to you and are your responsibility. We store them hashed and cannot recover a secret for you — a lost secret is rotated, not retrieved.
4.2 You will: keep credentials in a secrets store, not in source control; never embed a secret in client-side code, a mobile app binary, or anything a user can inspect; never share a credential between environments, customers or products; use a separate credential per environment; and rotate on a schedule and whenever a person with access leaves.
4.3 On a leak — what you must do. If a credential is or may be exposed, you will:
- Revoke or rotate it immediately through the partner portal;
- Notify us within twenty-four (24) hours at developers@packandkin.net, stating what was exposed, when, how, and the period of exposure;
- Tell each affected store, unless we direct otherwise because notice would prejudice an investigation;
- Preserve logs and cooperate with our investigation; and
- Provide a written summary of cause and remediation on request.
4.4 We may revoke, rotate or suspend any credential immediately where we believe it is compromised, is being misused, or threatens the security or availability of the Services. We will tell you as soon as we reasonably can, but we will act first.
4.5 You will not attempt to use a credential you were not issued, to extend a credential's reach beyond its scopes, or to determine another party's credentials.
5. Data
Read 5.1 first — it determines what the rest of this Section means.
5.1 Whose data it is, and what you become. Data you receive through a store's authorization is the store's data, and where it concerns the store's customers it is those people's personal information. When a store authorizes you and you receive that data, you receive it at the store's direction and you act as that store's own service provider — not as our subcontractor. Your obligations under this Section run to the store as well as to us, and each store whose data you receive is an intended third-party beneficiary of this Section 5 and may enforce it directly against you.
5.2 What you may store. You may store and cache data you receive, to the extent needed to operate, support and improve the integration you provide to that store. You may retain it for as long as you provide that integration to that store.
5.3 What you must never store. Regardless of any authorization:
- Credentials in plaintext or reversible form — yours, a store's, or a user's.
- Card numbers, security codes, or magnetic-stripe data. If your integration touches payment, it uses tokens. We do not hold this data and neither may you.
- Government identification documents and identity material obtained through the Services, including USPS Form 1583 filings and their attachments, and merchant-boarding identity material such as Social Security numbers, dates of birth, and bank account and routing numbers.
- Mail content — scans of mail interiors or contents.
- Anything a scope did not authorize you to receive, including data returned to you in error.
5.4 Data returned in error. If you receive data you were not authorized to receive, you will stop processing it, notify us within twenty-four (24) hours, and delete it on our instruction. You will not examine it further, retain it, or use it.
5.5 Deletion.
- (a) On revocation. When a store revokes your authorization, or you stop providing your integration to it, you will delete or de-identify that store's data within
[DATA DELETION WINDOW], except where you are required by law to retain it or the store has separately asked you to keep it. - (b) On request. You will delete a store's data, or specific records within it, promptly on the store's written request, and you will confirm when it is done.
- (c) Consumer requests. If a store asks for your help responding to a request from one of its customers to know, delete or correct personal information, you will provide it. If a consumer contacts you directly about data you hold for a store, refer them to that store.
- (d) Backups. Data in backups may persist until the backup cycle expires, provided it is not restored into active use.
5.6 What you may not do with it. You will not: sell or share a store's data, or personal information within it; use it for your own marketing or to prospect the store's customers; combine it with data from another source except as needed for the integration the store engaged you for; use it to train a general-purpose machine learning model; use it to build a profile of a store, its volumes, or its pricing for any purpose other than serving that store; or disclose it to anyone other than a subprocessor bound to these obligations.
5.7 Aggregate insight. You may derive aggregated, de-identified statistics from data you lawfully hold, provided the result cannot reasonably be linked to a store, a person or a household, and provided you do not publish or sell anything that reveals an individual store's volumes, pricing or customers.
5.8 Security. You will maintain safeguards appropriate to the sensitivity of what you hold — encryption in transit and at rest, access control, logging, and prompt patching — and you will not store store data in a jurisdiction outside the United States without the store's consent.
5.9 Your own notice. You are responsible for your own privacy notice and for describing accurately what you collect from a store and why.
6. Fair use, rate limits and reliability
6.1 You will stay within published rate limits and will not circumvent them, including by distributing calls across credentials, clients or IP addresses.
6.2 You will: back off on 429 and 5xx responses using exponential backoff with jitter; not
poll where a webhook exists; request only the fields and pages you need; and cache responsibly rather
than re-fetching unchanged data.
6.3 Idempotency. Where an endpoint supports an idempotency key, you will use one for any request that moves money, buys a label, or creates a durable record. A retry without one may charge a store twice, and that is your liability, not ours.
6.4 We may throttle, suspend or revoke a credential generating abnormal load, and may do so immediately and without notice where availability for others is threatened.
6.5 We may set, publish and change limits. Limits are operational and are not a service commitment.
7. Fees
7.1 Some API activity is charged. Where a fee applies it is stated in the developer fee schedule published in the partner portal.
7.2 Per-attempt charging. Certain metered fees — including the fee for a label purchase through the API — are charged per attempt, not per success. A retried, failed or rejected call may still be billable. Design your integration accordingly, and note that §6.3's idempotency requirement is the practical control on this.
7.3 Fees are invoiced to you, and you will pay within the period stated on the invoice. Overdue amounts may result in suspension of your credentials.
7.4 We may change the developer fee schedule on thirty (30) days' notice. Continued use after the effective date is acceptance.
7.5 Your arrangements with a store are yours. What you charge a store is between you and the store. We do not collect it, do not guarantee it, and are not a party to it.
8. Webhooks
8.1 Webhook deliveries are signed. You will verify the signature on every delivery before acting on it, and you will reject anything unsigned or failing verification.
8.2 You will: respond quickly and process asynchronously; treat delivery as at-least-once and make your handler idempotent; tolerate out-of-order and duplicate deliveries; and tolerate unknown event types and unknown fields without failing.
8.3 We retry failed deliveries for a period and may disable an endpoint that fails persistently. A webhook is a notification, not a guarantee of delivery — reconcile from the API where correctness matters.
8.4 Your endpoint must be reachable over TLS and must not require credentials we cannot supply.
9. Versions, changes and deprecation
9.1 The API is versioned. We may add endpoints, fields and event types at any time; your integration must tolerate additive change, including unrecognized fields and enum values.
9.2 Breaking changes. For a change that breaks a documented interface in the current version we will give at least ninety (90) days' notice through the partner portal and to your registered contact, except where a shorter period is required by security, by law, or by a third party whose service the endpoint depends on.
9.3 Deprecation. A deprecated endpoint or version is announced with an end-of-life date and continues to function until then, after which it may be removed and calls may fail.
9.4 Documentation is the interface. Behavior not documented is not part of the interface, and you may not rely on it — including undocumented fields, error strings, ordering, timing, or anything inferred from observing responses.
9.5 You will keep your integration current and will migrate before an announced end-of-life date. We are not responsible for an integration that breaks because you did not migrate.
10. Branding and what you may claim
10.1 We grant you a limited, revocable, non-exclusive, non-transferable licence to use our name and marks solely to state, factually, that your product integrates with Pack & Kin Studio, in accordance with any brand guidelines we publish.
10.2 You may say: "Works with Pack & Kin Studio," "Integrates with Pack & Kin Studio," or a comparable factual statement.
10.3 You may not say or imply: that your product is built, endorsed, certified, approved, recommended or supported by us, unless we have agreed in writing; that you are a partner, reseller or authorized dealer, unless you are; that we are responsible for your product; or anything about our security, compliance or availability that we have not published. You will not use our marks in your product name, company name, domain, or social handle, and will not register anything confusingly similar.
10.4 Your product is yours. You are responsible for it, for its support, and for what you tell your own customers. We do not review, approve or endorse it, and listing it in a directory is not endorsement.
10.5 We may require you to stop using our marks, and to correct a statement, at any time.
11. Prohibited conduct
In addition to the Acceptable Use Policy, you will not: probe, scan or test the security of the Services except under the Acceptable Use Policy's security-research section; attempt to access data, stores or accounts you are not authorized to access; reverse engineer the Services or the API beyond what documentation supports; use the Developer Services to build a competing platform, or to benchmark for a competitor; scrape, enumerate or bulk-extract data beyond what your integration requires; misrepresent your identity or your integration's function to a store; introduce malware, or use the Services to attack anyone; or interfere with another developer's integration.
12. Intellectual property
12.1 We own the Services, the API, the SDKs, the documentation and all intellectual property in them. You get only the limited rights in these Terms. Pack & Kin and Pack & Kin Networks are trademarks of Mail and More LLC, which trades under them; "Pack & Kin" in these Terms means Mail and More LLC, and all goodwill from your use of the marks under §10 accrues to it.
12.2 SDKs. SDKs and sample code we publish may be used to build and operate your integration, subject to any licence file distributed with them, which controls if it conflicts with this Section.
12.3 You own your integration and your own code. We claim nothing in it.
12.4 Feedback. Anything you tell us about the API — a suggestion, a bug report, a request — may be used by us freely, without obligation to you.
12.5 You will not remove proprietary notices, and will reproduce them in any permitted copy.
13. Warranties, liability and indemnity
13.1 DISCLAIMER. THE DEVELOPER SERVICES ARE PROVIDED "AS IS" AND "AS AVAILABLE." WE DISCLAIM ALL WARRANTIES, EXPRESS, IMPLIED AND STATUTORY, INCLUDING MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. WE DO NOT WARRANT THAT THE API WILL BE AVAILABLE, UNINTERRUPTED, ERROR-FREE, OR THAT ANY ENDPOINT, FIELD OR EVENT WILL CONTINUE TO EXIST. WE MAKE NO SERVICE LEVEL COMMITMENT AND OFFER NO CREDITS.
13.2 No commitment about stores. We do not guarantee that any store will authorize you, will continue to authorize you, or will remain on the platform. We may change the product in ways that make your integration less useful or unnecessary.
13.3 Your indemnity. You will defend, indemnify and hold harmless Pack & Kin and its affiliates from any third-party claim, and all resulting losses, damages, liabilities, fines, penalties and reasonable attorneys' fees, arising out of or relating to: your integration and your product; your handling of a store's data, including any breach of Section 5; your credentials and any compromise of them; anything you told a store or a store's customers; your breach of these Terms or the Acceptable Use Policy; and any claim by a store arising from your acts or omissions.
13.4 Our indemnity. We will defend you against a third-party claim that the API or an SDK, used as these Terms permit, infringes a U.S. patent, copyright, trademark or trade secret. This is our only indemnity obligation here, and the exclusions in Section 15.3 of the Platform Terms of Service apply.
13.5 EXCLUSION. NEITHER PARTY WILL BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, EXEMPLARY OR PUNITIVE DAMAGES, OR FOR LOST PROFITS, LOST REVENUE, LOST BUSINESS OR LOST DATA, even if advised of the possibility.
13.6 CAP. OUR TOTAL AGGREGATE LIABILITY WILL NOT EXCEED THE GREATER OF THE FEES YOU PAID US IN THE TWELVE (12) MONTHS BEFORE THE EVENT GIVING RISE TO THE CLAIM, OR $1,000. This does not limit your obligations under Sections 5, 7 or 13.3, or either party's liability for fraud, willful misconduct, or misappropriation of intellectual property.
13.7 Time limit. Any claim must be brought within one (1) year after it accrues.
14. Term, suspension and termination
14.1 Term. These Terms begin on your acceptance and continue until terminated.
14.2 By you. At any time, by ceasing use and closing your developer account.
14.3 By us. On thirty (30) days' notice for convenience, or immediately for: breach of Sections 3, 4, 5, 10 or 11; a security risk; suspected misuse of a store's data or authorization; non-payment; a legal or third-party requirement; or conduct that harms a store's confidence in the platform.
14.4 Suspension. We may suspend your credentials immediately, including while we investigate. Where practicable we will suspend narrowly.
14.5 Effect. On termination: your credentials stop working; every store authorization ends; you will stop using our marks and remove claims of integration; and you will delete store data under Section 5.5(a), which survives termination.
14.6 Tell your customers. If your access ends, you are responsible for telling the stores relying on your integration, promptly and accurately. We may also tell them that your access has ended.
14.7 Survival. Sections 5, 10.3, 11, 12, 13, 14.5–14.7, 15 and 16 survive.
15. Dispute resolution
15.1 Informal resolution first, by written notice and a thirty (30) day good-faith period.
15.2 Arbitration. Any unresolved dispute will be resolved by binding individual arbitration administered by the American Arbitration Association under its Commercial Arbitration Rules, before one arbitrator, seated in **Arizona**. The Federal Arbitration Act governs.
15.3 CLASS WAIVER. DISPUTES WILL BE ARBITRATED ONLY ON AN INDIVIDUAL BASIS. No class, collective, consolidated or representative proceeding.
15.4 JURY WAIVER. EACH PARTY WAIVES ANY RIGHT TO A JURY TRIAL.
15.5 Carve-outs. Small claims, and injunctive relief in court to protect intellectual property, Confidential Information, or to address unauthorized access.
15.6 Venue. For anything not arbitrated, the exclusive jurisdiction of the state and federal courts in Arizona****.
15.7 Opt-out of §§15.2–15.4 by written notice to legal@packandkin.net within thirty (30) days of first acceptance.
16. General
16.1 Governing law. The State of Arizona****, excluding conflict-of-laws rules.
16.2 Changes. We may revise these Terms by publishing a new version, with thirty (30) days' notice of a material change. A material change may require re-acceptance before your credentials continue to work — see Section 2.2.
16.3 Assignment. You may not assign without our written consent; a change of control is an assignment. We may assign freely. A store's authorization does not transfer with your business — an acquirer must obtain fresh authorization from each store.
16.4 Notices. To us at legal@packandkin.net; to you at your registered contact or by notice in the partner portal.
16.5 Independent contractors. Nothing creates a partnership, joint venture, agency or employment relationship.
16.6 Third-party beneficiaries. None, except that a store whose data you receive is an intended beneficiary of Section 5, as §5.1 states.
16.7 Entire agreement, superseding prior discussions on the subject. Severability, no waiver and force majeure apply as in Sections 19.4, 19.9 and 19.10 of the Platform Terms of Service.