App Listing Standards
Effective Date: October 15, 2026 Version: 1.0 Applies to: All Developers who submit an Application for listing in the App Marketplace and all Publishers of a listed Application.
Article 1: Introduction and Scope
1.1 This document states the content standards for a marketplace Listing: what a submission shall contain, the function, experience, performance, privacy, and security standards an Application shall meet, the review procedure, and the duties that continue after publication. Distribution itself is governed by the App Marketplace Terms; this document controls for Listing content and review outcomes in the event of a conflict with that document.
1.2 If a provision of this document conflicts with the Terms of Use, this document controls for its subject. Policies and help pages explain this document; they do not amend it.
Article 2: Definitions
2.1 In this document, terms defined in the Developer Agreement and in the App Marketplace Terms have the same meaning, and Core Flow: the principal task the Listing advertises, for example synchronization of Orders to a warehouse system or reconciliation of returns.
Material Change: a change described in clause 10.3.
Article 3: Submission Package
3.1 A submission is complete only when the developer portal contains all of the following: (a) a functional description in plain language: what the Application does, who uses it, and what Platform surfaces it touches; (b) images or a recording of the actual Application as submitted: no representation of a screen that does not exist in the build under review; (c) each exact scope requested, with a justification per scope tied to a concrete feature, in accordance with the OAuth App Registration and Review; (d) a support contact that meets the standard in the Partner Support and Incident Escalation Policy; (e) the address of a privacy statement whose data practices match the data-retention statement required by the Data Use, Retention and Deletion; (f) full pricing with every fee disclosed, with no hidden charge and no introductory price that conceals a required charge, with renewal and any overage stated on the Listing, in accordance with the App Marketplace Terms; and (g) a declaration of the integration surface: each Platform interface the Application exercises, stated by its function, so that review tests exactly the interfaces declared.
3.2 A description shall not claim an endorsement, a certification, or a partnership status beyond the status the Publisher holds. Certified status arises only under the Integration Certification Policy; provider status arises only under the Solution Provider Program; use of a mark follows the Developer Brand and Trademark Use (Developer Brand and Trademark Use Policy). A claim of a capability the Platform does not offer is a ground for rejection under Article 10.
Article 4: Function Standard
4.1 The Application shall perform every function the Listing advertises, end to end, in the Sandbox, without the reviewer altering a configuration by hand to make the function operate. Review proceeds by installation, by creation of test Orders in the Sandbox, and by observation of the result in the Application.
4.2 Error handling is part of the standard. The Application shall handle each real failure of an interface it exercises and shall present the Installer with an actionable statement: an authentication failure, with a direction to re-authenticate and not a blank screen; a missing Order or Product, with a statement of what is missing and how to recover; a rate-limit response, with backoff in accordance with the API Rate Limits and Quotas and a visible statement that synchronization is paused and retrying; and a validation rejection, with the field named and not a general error statement. An Application that conceals a failure and presents outdated data fails review.
4.3 Accuracy for a commerce Application is mandatory. An Application that reconciles Orders shall present the same Order set as the Seller's own record for the same tenant, with no silent omission and no invented row. An Application that writes a Product or a shipping record shall confirm the write by a subsequent read and shall present a conflict rather than overwriting without notice. Review includes examination against test data prepared for review; a mismatch is a rejection.
4.4 Uninstall shall be clean. Revocation of an Install shall revoke the Application's access, shall stop every polling operation and every webhook processing operation for that tenant, and shall start the deletion duties in the Data Use, Retention and Deletion. An Application that continues synchronization after Uninstall fails on security grounds under Article 8.
Article 5: Experience Standard
5.1 An Installer with no prior knowledge of the Application shall reach a first successful completion of the Core Flow from a fresh Install without outside help. A setup guide, a sensible default, and guidance presented at the point of error satisfy this clause; a requirement to contact support for configuration does not.
5.2 Every Application shall present a settings surface inside the Application stating: what is synchronized, how often, how to pause synchronization, and how to disconnect. A setting that exists only in correspondence with the Publisher is a ground for rejection.
5.3 Listing images shall depict the current major version. Where the issued interface has diverged visibly from the Listing images, the Listing is outdated under Article 11 and the Publisher has thirty (30) days from notice to refresh the assets or accept removal.
5.4 Installer-facing wording shall state a limit honestly. An Application that synchronizes at an interval shall state the interval; an Application that covers only a subset of products shall state the subset. A limit discovered only by use is misrepresentation under Article 9.
Article 6: Performance Standard
6.1 An Installer-facing surface shall meet the following, measured in review in the Sandbox against prepared data: the ninety-fifth percentile rendering time for a page or screen is under two (2) seconds, and the ninety-fifth percentile time for an interactive act, including search, filter, and a synchronization trigger, is under five (5) seconds. An occasional excess does not fail review; a sustained pattern of slowness does.
6.2 Conduct on a rate-limit response is assessed separately from speed. The Application shall observe the API Rate Limits and Quotas: honour a stated retry period, increase the interval between retries, and never distribute retries among keys to evade a limit, which is circumvention and fails the submission outright. Review deliberately produces a rate-limit response; an Application that ceases to operate, stalls without a statement, or discards queued work silently fails.
6.3 Background processing shall have no duplicate effect. An Application that consumes an event or that polls shall deduplicate on a stable event identifier, so that a redelivered event never creates or updates a record twice. Review sends a duplicate event; a double effect is a rejection.
Article 7: Privacy Review
7.1 Privacy review is conducted against the Data Use, Retention and Deletion. The reviewer compares three records: the scopes requested, the data-retention statement, and the privacy statement address in clause 3.1(e). The three records shall agree. An Application that requests broad read access while the retention statement states that nothing is stored fails, because the statements cannot both be true.
7.2 Minimization is assessed, not advised. An Application whose Core Flow is display of the current day's Orders has no justification for a historical export scope or for retention beyond the period its own statement declares. Excess collection is a rejection with a stated correction: narrow the scopes or narrow the claims.
7.3 An Application whose principal purpose is collection of Buyer, Seller, or Order data for resale, enrichment, or unrelated profiling is prohibited outright. Such an Application is rejected under this document and under the Data Use, Retention and Deletion, and the matter is referred under Article 12; no narrowing of scope cures the purpose.
Article 8: Security Review
8.1 Security review is conducted against the Partner Security Requirements, on the checklist the Publisher certifies under Article 11: an encrypted connection at the standard that document requires on every connection the Application makes; no secret in a client package or a published file; a secret held on the server side only and read from a protected store; and a session credential handled with the protections the Platform applies to such a credential.
8.2 Each of the following is an automatic failure on security grounds, with rejection and resubmission and no remediation period in which the Listing proceeds: (a) a Platform secret, a service credential, or an API credential present in client-side code, a public repository, or a published package; (b) transmission of a credential or personal data over an unencrypted connection; (c) recording of a secret, a token, or Buyer personal data in a plain log the Publisher retains; and (d) absence of validation of data the Application forwards to the Platform, where every write shall be validated for type, range, and account scope before transmission.
8.3 A finding that carries a remediation period includes a defect in file hygiene for dependencies, a correction period exceeded under the Partner Security Requirements, and absence of an incident-response contact. The Publisher has thirty (30) days to remediate and to resubmit for security approval; the Listing does not publish until approval is given.
Article 9: Content Rules for a Listing
9.1 The following are prohibited in a Listing and in Installer-facing wording inside the Application: a deceptive claim about what the Application does; a false, purchased, or rewarded review; repetition of a search term in a title or description to manipulate ranking; a link that routes an Installer to a competing marketplace; and a claim of endorsement, certification, or partnership not held under the Solution Provider Program, the Integration Certification Policy, or the Developer Brand and Trademark Use (Developer Brand and Trademark Use Policy).
9.2 Pricing wording shall match the App Marketplace Terms exactly: every fee an Installer pays appears on the Listing, and "free" means free with no paid release required for the advertised Core Flow. A Listing described as free whose Core Flow requires a paid plan the Listing does not mention is deceptive pricing.
9.3 A comparative claim against another marketplace Application shall be true and verifiable as of the Listing date. Review examines the two most prominent comparative claims; a false claim fails the submission.
Article 10: Review Procedure and Rejection
10.1 The review period is ten (10) business days from a complete submission. A submission missing an item in Article 3 does not start the period, and the portal states exactly what is missing. The Company tests the Core Flow in the Sandbox, verifies scope necessity, checks Listing accuracy, and conducts the privacy review in Article 7 and the security review in Article 8.
10.2 The outcomes are: approval, under which the Listing publishes; approval with conditions, under which the Listing publishes with named conditions and a compliance date, a missed condition being handled under Article 11; and rejection with stated reasons citing the specific rule in Articles 3–9 that was not met and the evidence relied on.
10.3 A Material Change requires re-review before release: a new scope or new data collection, a pricing change, a change of ownership, or a change to the Core Flow the Listing advertises. Release of a Material Change without re-review is a violation handled under Article 12, and the Listing is withdrawn until the change passes review.
10.4 The rejections issued most often, with the rule violated and the correction required, are as follows. Each correction, once made, permits resubmission without a waiting period, except as clause 10.5 provides for a deceptive resubmission (a) Images show an interface that does not exist in the submitted build: Article 3: issue the interface first, or depict the build under review.
(b) Broad read scopes requested for a narrow feature, on the ground of a possible future need: Article 7: narrow the scopes to what the Core Flow uses at present, and request more later with re-review.
(c) The Core Flow requires a manual configuration the Listing does not mention: Article 5: automate the setup, or state every manual step in the Listing.
(d) A rate-limit response in review causes a failure, a stall, or silent loss of data: Article 6: implement backoff, honour the stated retry period, and present the paused state.
(e) A duplicate event creates a record twice: Article 6: deduplicate on a stable identifier before an effect is applied.
(f) A service credential or secret found in a client package: Article 8: move every secret to the server side, read each secret from a protected store, and rotate the exposed credential in accordance with the API Key Management and Rotation.
(g) A pricing page conceals a required paid plan behind a description as free: Article 9: disclose every fee on the Listing before resubmission.
(h) The privacy statement contradicts the data-retention statement: Article 7: align the scopes, the retention statement, and the privacy statement, and resubmit.
(i) An error path presents a general error statement with no recovery direction: Article 4: name the failure and the next step for each real failure mode.
(j) The Application continues polling after Uninstall: Article 4: revoke access and halt every tenant operation on Uninstall, and honour the deletion duties in the Data Use, Retention and Deletion.
10.5 A Publisher whose submission is rejected may resubmit after remediation. A repeated deceptive submission: the same false claim filed again after a rejection that cited the claim: is cause for suspension of the Publisher under Article 12.
Article 11: Self-Certification and Quality After Publication
11.1 Before submitting, the Publisher shall examine the Application against each item in this clause and shall attest to each item in the portal. An attestation is a representation; a false attestation discovered in review or after Listing is a conduct violation under the Partner Code of Conduct. The items are (a) Every advertised function operates end to end in the Sandbox without manual intervention.
(b) Each real failure mode: authentication failure, a missing record, a rate-limit response, and a validation rejection: presents the Installer with an actionable recovery path.
(c) A commerce read agrees with the Seller's own record for the same tenant, and a write is confirmed by a subsequent read.
(d) Uninstall revokes access, stops every operation, and starts the deletion period in the Data Use, Retention and Deletion.
(e) First use reaches a successful Core Flow with no outside help, and a settings surface exists inside the Application.
(f) The performance figures in clause 6.1 are met, and a rate-limit response produces backoff and never a distributed retry.
(g) A duplicate event is deduplicated on a stable identifier before an effect applies.
(h) The scopes, the data-retention statement, and the privacy statement agree, and collection is limited to what the Core Flow requires.
(i) Every connection is encrypted to the standard in Article 8, no secret is present in client code, a repository, or a package, and no log contains a secret or Buyer personal data.
(j) Listing wording is accurate: images match the build, pricing discloses every fee, and no endorsement claim exceeds the status held.
11.2 An average Installer rating below two and one-half (2.5) stars over ninety (90) days triggers a mandatory remediation plan within thirty (30) days. Failure to remediate is cause for removal of the Listing under the App Marketplace Terms.
11.3 A Listing with no update in twelve (12) months while the Application has issued a new major version is flagged as outdated. The Publisher has thirty (30) days from notice to refresh the assets or accept removal.
11.4 Removal in the middle of a period does not erase a money duty: revenue accrued through the removal date is settled under the Partner Revenue Share Policy, and the deletion duties in the Data Use, Retention and Deletion apply in full.
Article 12: Liability
12.1 Exclusion of certain damages. To the fullest extent permitted by law, neither party is liable to the other for indirect, incidental, special, punitive, or consequential damages, or for lost profits, lost revenue, or loss of goodwill, arising out of or relating to this document, even if the party has been advised of the possibility of those damages.
12.2 Cap. To the fullest extent permitted by law, the Company's total liability arising out of or relating to this document shall not exceed the greater of (a) the amounts the Developer paid to the Company under this document in the twelve months before the event giving rise to the claim, or (b) one hundred dollars ($100).
12.3 Carve-outs. This article does not limit (a) a party's indemnification obligations under this document; (b) liability for fraud or willful misconduct; (c) amounts the Developer owes for Orders, fees, chargebacks, or refunds under this document; or (d) liability that cannot be limited under applicable law.
12.4 Essential purpose. The parties agree that this article allocates risk between them, that it is an essential part of the basis of their bargain, and that it applies even if a limited remedy fails of its essential purpose.
Article 13: Indemnification
13.1 Duty. The Developer shall indemnify, defend, and hold harmless the Company and its members, managers, employees, and agents from and against every claim, demand, action, loss, liability, judgment, settlement, cost, and expense (including reasonable attorneys' fees) arising out of or relating to: (a) the Developer's breach of this document, including a false attestation under Article 11; (b) the Developer's Applications and Listings; (c) the Developer's violation of any law or of the rights of any person; and (d) taxes for which the Developer is responsible under this document.
13.2 Procedure. The Company shall give prompt written notice of a claim under this article. The Developer shall control the defense with counsel reasonably acceptable to the Company. The Company may participate in the defense at its own expense. The Developer shall not settle a claim in a manner that imposes any obligation or restriction on the Company, or that does not release the Company fully, without the Company's prior written consent.
13.3 Survival. This article survives the termination of this document.
Article 14: Enforcement and Appeals
14.1 Investigation. The Company may investigate any suspected violation of this document. The Developer shall cooperate with an investigation and shall produce the records this document requires the Developer to keep, including review records and attestations.
14.2 Notice. If the Company determines that the Developer has violated this document, the Company shall give written notice stating the provision violated and the facts relied on, except where notice would compromise an investigation of fraud, a safety risk, or a legal obligation.
14.3 Opportunity to cure. Where a violation is capable of cure, the Developer has ten (10) business days from notice to cure it and to confirm the cure in writing, except where Article 8 or Article 10 or Article 11 states a different period for the matter concerned, in which case that period applies. No cure period applies to an Application described in clause 7.3, to a deceptive submission, to fraud, or to a violation that by its nature cannot be cured.
14.4 Measures. If a violation is established and is not cured within the period allowed, the Company may, proportionate to the violation: (a) issue a written warning; (b) reject a submission or withdraw a Listing pending re-review; (c) suspend or remove the Listing and suspend the Publisher, in accordance with the App Marketplace Terms; (d) suspend or revoke a Credential; (e) suspend the Account or a program participation, in whole or in part; (f) terminate this document and the Account; and (g) exercise any other right or remedy available under this document or at law. Procedure is further governed by the Partner Suspension, Termination and Appeals.
14.5 Appeal. The Developer may appeal a measure under this article, including a rejection that the Developer contends misstates the evidence, by written notice to legal@aapawz.com within thirty (30) days of the measure, stating the grounds and attaching the records relied on. The appeal is decided by a person who did not make the original decision. The Company's decision on appeal is final. A measure remains in effect during an appeal unless the Company directs otherwise in writing.
14.6 No waiver by delay. The Company's delay in acting on a violation is not a waiver of the violation or of any later violation of the same kind.
Article 15: Term and Termination
15.1 Term. This document takes effect when the Developer first submits an Application for listing and continues until terminated under this article or until the Developer Agreement terminates, whichever occurs first.
15.2 Termination by the Company. The Company may terminate this document on thirty (30) days' written notice for any reason, and immediately on written notice if the Developer materially breaches this document, engages in fraud, or becomes ineligible to participate.
15.3 Termination by the Developer. The Developer may terminate this document on thirty (30) days' written notice to support@aapawz.com, provided the Developer has no investigation outstanding and no Listing published.
15.4 Effect of termination. On termination: (a) every Listing is withdrawn, with settlement and deletion in accordance with clause 11.4; (b) obligations that arose before termination survive until satisfied; and (c) the Company shall pay amounts owed, less amounts the Company may set off under this document, within thirty (30) days, except amounts held in connection with an open investigation or dispute.
15.5 Survival. The Definitions, Liability, Indemnification, Enforcement and Appeals (for measures taken before termination), Dispute Resolution, and General Provisions articles survive termination.
Article 16: Dispute Resolution
16.1 Any dispute arising out of or relating to this document, or to the relationship it governs, is governed by the Dispute Resolution Policy, which is incorporated into this document by reference.
Article 17: General Provisions
17.1 Amendments. The Company may amend this document by posting the amended document in the Document Center and giving notice to the Developer at the email address in the Account. An amendment that materially increases the Developer's fees or obligations takes effect thirty (30) days after notice; other amendments take effect on posting. Continued use of the Platform after the effective date of an amendment is acceptance of it. If the Developer does not accept an amendment, the Developer's remedy is to terminate under Article 15 before the amendment takes effect.
17.2 Notices. Legal notices under this document shall be sent to legal@aapawz.com. Operational notices and all other communications shall be sent to support@aapawz.com. A notice to the Company is effective when the Company acknowledges receipt or, for email, one business day after sending, whichever is earlier. Notices to the Developer are effective when sent to the email address in the Account or posted to the Account's notice facility in the portal, whichever occurs first. The Developer shall keep the email address in the Account current. DMCA notices are given as provided in the DMCA and Copyright Policy, to the designated agent at legal@aapawz.com.
17.3 Governing law. This document is governed by the laws of the State of Tennessee, without regard to its conflict-of-laws rules. Subject to the Dispute Resolution Policy, any proceeding arising out of this document shall be brought in the state or federal courts located in Shelby County, Tennessee, and the parties consent to personal jurisdiction there.
17.4 Severability. If any provision of this document is held unenforceable, the provision shall be enforced to the fullest extent permitted, and the remaining provisions continue in full effect.
17.5 Entire agreement. This document, together with the documents it incorporates by reference, is the entire agreement between the Company and the Developer for the subject it governs and supersedes every prior or contemporaneous statement, communication, or agreement on that subject, whether written or oral.
17.6 Assignment. The Developer shall not assign this document or any right or obligation under it without the Company's prior written consent, and an assignment without consent is void. The Company may assign this document to an affiliate or in connection with a sale of all or part of its business, on notice to the Developer.
17.7 Waiver. A waiver of any provision of this document is effective only in writing and only for the instance stated. No waiver is a waiver of any other provision or instance.
17.8 Interpretation. Headings are for convenience only. "Including" means "including without limitation." This document shall not be construed against a party on the ground that the party prepared it. The English-language text controls over any translation.