# Priority Cloud (Priority ERP) — integration documentation > Machine-readable rendition of Priority Cloud (Priority ERP) simulator documentation. The machine contract named in the overview below is the authority on request and response shapes; this page carries what a schema cannot say — what is deliberately unsupported, what the real product documents that this simulator does not implement, what each error code means, and the workflows. API version: `OData v4` A tenant-isolated simulation of Priority ERP's OData v4 REST surface, wire-verified against the official Priority sandbox. Served under https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo — the real product's /odata/Priority/{config-file}/{company} shape, where both segments are instance configuration. Discovery is OData-native: the service document lists every entity set, and $metadata is the machine-readable contract, with every property name and EDM type taken from the real instance's own document. Every wire behaviour reproduces a measurement of the official sandbox, recorded with its evidence in the conformance ledger. Where the shared sandbox itself answers identical requests differently by backend version (eighteen such surfaces are known), this simulator commits to one coherent version and documents the choice. Where Priority could not be verified, the capability is absent and the ledger says why — nothing here is guessed. ## Terminology | Term | Definition | | --- | --- | | {environmentKey} | A PLACEHOLDER, not a literal: SUBSTITUTE {environmentKey} in every URL below with your own environment's key — 'env_' followed by 32 hexadecimal characters — or nothing on this page runs. The concrete value is on the ERP simulator page in the app, under Connection configuration → Environment key; that in-app copy of this document renders every URL with your key already filled in, so copying from there is the shortest path. The key ROUTES the request and is not a credential: it is safe in a URL, and it is checked BEFORE authentication, so an unknown one answers a 404 problem document (application/problem+json, code SIM-1000) whatever credential accompanies it. SIM-1000 therefore always means a wrong key, never a wrong password — a real key with a bad password answers the empty 401 instead, and so does a valid credential sent to a DIFFERENT existing environment's key. | | Entity set / form | Priority exposes its FORMS as OData entity sets; names are the internal form names (CUSTOMERS, AINVOICES, TINVOICES). | | Subform | A child collection navigation, suffixed _SUBFORM (AINVOICEITEMS_SUBFORM = invoice lines). | | IVNUM / DEBIT / IVTYPE | The composite key of financial documents. IVTYPE 'A' = sales invoice, 'T' = receipt. Drafts carry temporary T-prefixed IVNUMs; finalization assigns the book number (IN..., RC...). | | FINAL / STATDES | FINAL 'Y' with STATDES 'Final' marks a finalized document; drafts have FINAL null and STATDES 'Draft'. Cancellation adds a REVERSING row (negative totals, STATDES 'Canceled') beside the surviving original. | | TFNCITEMS (applications) | A receipt's application rows: each CREDIT is applied against the invoice named by FNCIREF1. No rows = an UNAPPLIED receipt; several rows = one receipt settling several invoices. | ## Base URLs | Purpose | Template | | --- | --- | | OData service root | `https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo` | | $metadata | `https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/$metadata` | | Entity set | `https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS` | ## Authentication ### HTTP Basic authentication (REST) Every request. There is no token endpoint — the real product authenticates each OData call with Basic credentials (an API user). Required: - API username - API password (minted once in Settings → ERP; stored as a hash) **Call any resource with -u** ```bash curl -u API_USER:API_PASSWORD 'https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS?$top=1' ``` Success response: ```json {"@odata.context":"...$metadata#CUSTOMERS","value":[{"CUSTNAME":"100001", "...": "..."}]} ``` Credentials do not expire; revoke them in Settings → ERP. | Status | Meaning | | --- | --- | | 401 | Missing or wrong credential. The body is EMPTY and WWW-Authenticate: Basic is set (no realm) — measured; do not expect a JSON envelope. | ### Personal Access Token (PAT) (REST) Automated server-to-server integrations (real product v19.1+). A PAT belongs to a Priority USER: requests authenticate AS that user (OWNERLOGIN on written rows, GetLoginName). Required: - A token minted in Settings → ERP (shown once; only a digest is stored) **Send the token as the Basic USERNAME with the literal password PAT — every example in this document works unchanged with a PAT in place of API_USER:API_PASSWORD** ```bash curl -u API_PAT:PAT 'https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/GetLoginName' ``` Success response: ```json {"@odata.context":"...$metadata#Edm.String","value":""} ``` Tokens do not expire; revoke them in Settings → ERP. A revoked or unknown token answers the same empty 401. | Status | Meaning | | --- | --- | | 401 | The same empty-body 401 as Basic, and it covers THREE indistinguishable cases: an unknown token, a revoked token, and a token that belongs to a DIFFERENT environment (credentials are per-environment — a valid token on the wrong environment key answers this too). The password must be the LITERAL string PAT; anything else is treated as an ordinary Basic credential. | ## First request Substitute {environmentKey} before running anything (see Terminology); a 404 SIM-1000 means you have not. Discover the surface from the service document, then read a collection. Everything — including $metadata — requires Basic auth. SINGLE-QUOTE the URL in a shell: OData options start with $, and a double-quoted "?$top=5" is expanded by bash to "?=5", which the wire silently ignores — you get every row and no error. And PERCENT-ENCODE spaces: the parameter tables print filters like $filter=CUSTNAME eq '100001' with literal spaces for readability, but a URL cannot carry raw spaces (curl rejects it outright) — send %20 (quotes may stay literal or be %27). ```bash curl -u API_USER:API_PASSWORD 'https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo' ``` Response: ```json {"@odata.context":"https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/$metadata","value":[{"name":"ACCOUNTS_RECEIVABLE","kind":"EntitySet","url":"ACCOUNTS_RECEIVABLE"}, {"name":"AINVOICES","kind":"EntitySet","url":"AINVOICES"}, "..."]} ``` Page with $top and $skip against a stable $orderby. There is no server cursor and $count is silently ignored — walk until a page comes back short. ## Pulling data **List** ```bash curl -u API_USER:API_PASSWORD 'https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/AINVOICES?$top=10&$orderby=IVDATE%20desc' ``` **Single record** ```bash curl -u API_USER:API_PASSWORD "https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/AINVOICES(IVNUM='IN254000001',DEBIT='D',IVTYPE='A')" ``` **Filter** ```bash curl -u API_USER:API_PASSWORD 'https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/AINVOICES?$filter=FINAL%20eq%20%27Y%27%20and%20TOTPRICE%20gt%20500' ``` **Page loop** ```bash # $count is ignored: page until short curl -u API_USER:API_PASSWORD 'https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS?$orderby=CUSTNAME&$top=50&$skip=0' ``` **Field projection** ```bash curl -u API_USER:API_PASSWORD 'https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS?$select=CUSTNAME,CUSTDES,PAYCODE' ``` **Embedded children** ```bash curl -u API_USER:API_PASSWORD 'https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/TINVOICES?$expand=TFNCITEMS_SUBFORM,TPAYMENT2_SUBFORM&$top=5' ``` Response envelope: | Field | Description | | --- | --- | | @odata.context | The $metadata fragment describing the payload; narrows with $select (…#CUSTOMERS(CUSTNAME,CUSTDES)) with DUPLICATE entries deduped, echoes $select=* as (*), and echoes each expanded navigation with its nested projection — $expand=CUSTPERSONNEL_SUBFORM($select=NAME) yields …#CUSTOMERS(CUSTPERSONNEL_SUBFORM(NAME)), an unnarrowed expand CUSTPERSONNEL_SUBFORM() (all measured). | | value | The row array on COLLECTION reads. Item reads put properties at the top level with a …/$entity context and no value wrapper. | ## Writing data ### Create a customer (draft numbering, server fills) POST to the collection. With no CUSTNAME the form assigns a TEMPORARY number (T-...) and STATDES 'Potential'; with an explicit CUSTNAME the record lands 'Active'. The 201 carries the FULL entity — OWNERLOGIN (the caller), CREATEDDATE/STATUSDATE (today, date-only midnight Z) and the CUST auto-unique are server-filled — plus a Location header with quotes percent-encoded. Children may ride along as subform arrays and are echoed back (context #CUSTOMERS(CUSTPERSONNEL_SUBFORM())). Re-running this exact command answers the measured 409, because the key already exists. ```bash # answers: 201 or 409 curl -u API_USER:API_PASSWORD -X POST -H 'Content-Type: application/json' -d '{"CUSTNAME":"DOCS-EXAMPLE-1","CUSTDES":"Docs example"}' 'https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS' ``` Response: ```json {"@odata.context":"...$metadata#CUSTOMERS/$entity","CUSTNAME":"DOCS-EXAMPLE-1","CUSTDES":"Docs example","STATDES":"Active","OWNERLOGIN":"","CREATEDDATE":"T00:00:00Z", "...": "..."} ``` - An EMPTY payload answers the measured missing-required refusal (InterfaceErrors, instance language: שורה 1- - חסר מס. לקוח). - An unknown property answers 400 'The property 'X' does not exist on type ...'; a wrong JSON type answers the Cannot-convert envelope with a populated innererror. - STATDES must be a status this instance carries ('Active', 'Potential') — anything else answers the measured value-not-in-table refusal. ### Update (PATCH) — and the read-back rule PATCH a keyed item with the columns to change; the response is 200 with the full entity. WRITABLE columns apply (the field tables mark them); SERVER-OWNED columns — keys, computed amounts, INACTIVEFLAG, FINAL — are SILENTLY IGNORED while the response still answers 200 (measured). A 200 PATCH is therefore NOT proof a property changed: read back. There is a THIRD outcome the Read-only flag does not distinguish: a column the FORM validates against another table refuses the WHOLE write with an InterfaceErrors 400 instead of ignoring it. There are two, and they belong to DIFFERENT forms: on AINVOICES, REFERENCE is validated against a customer-orders table this book does not carry, so every value that reaches the lookup is refused — the two that do NOT reach it are the empty string and an explicit null, which both answer 200 and leave the column null (so clearing REFERENCE works while setting it cannot); on CUSTOMERS, STATDES is validated against the instance's status list, so a value outside it is refused the same way (REFERENCE is not a CUSTOMERS column at all — sending it there draws the ordinary 'property does not exist' 400). Read the flag as 'your value may not survive', never as 'your write will be accepted'. ```bash # answers: 200 curl -u API_USER:API_PASSWORD -X PATCH -H 'Content-Type: application/json' -d '{"CUSTDES":"Docs example updated"}' "https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS('DOCS-EXAMPLE-1')" ``` Response: ```json {"@odata.context":"...$metadata#CUSTOMERS/$entity","CUSTNAME":"DOCS-EXAMPLE-1","CUSTDES":"Docs example updated", "...": "..."} ``` - PATCH of a missing key answers 400 'A record with the specified key was not found' (not 404 — measured). ### Create an invoice draft with lines POST to AINVOICES with a CUSTNAME that EXISTS (an unknown customer answers the measured value-not-in-table refusal) and optionally AINVOICEITEMS_SUBFORM lines (PARTNAME required — this book publishes no parts catalog, so any PARTNAME is accepted as given; the REAL product validates it against its parts table). The draft gets a T-number, STATDES 'Draft', FINAL null, CDES echoing the customer description, and header totals = Σ lines. Each run of this example creates a NEW draft. ```bash # answers: 201 curl -u API_USER:API_PASSWORD -X POST -H 'Content-Type: application/json' -d '{"CUSTNAME":"100001","AINVOICEITEMS_SUBFORM":[{"PARTNAME":"DOC-PART","TQUANT":2,"PRICE":10}]}' 'https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/AINVOICES' ``` Response: ```json {"@odata.context":"...$metadata#AINVOICES(AINVOICEITEMS_SUBFORM())/$entity","IVNUM":"T123459...","STATDES":"Draft","FINAL":null,"TOTPRICE":20,"AINVOICEITEMS_SUBFORM":[{"KLINE":1,"PARTNAME":"DOC-PART","TQUANT":2,"QUANT":2,"QPRICE":20,"TOTPRICE":20, "...": "..."}]} ``` - Line ops on a draft you created: POST /AINVOICEITEMS_SUBFORM adds a line (201, Location ...AINVOICEITEMS_SUBFORM()); PATCH .../AINVOICEITEMS_SUBFORM() recomputes QUANT and the amount identity; DELETE .../AINVOICEITEMS_SUBFORM() answers 204 — the ONE deleting write. Header totals follow every line change. - PATCHing REFERENCE answers the measured refusal: the form validates it against customer orders, and this book has none. - THE DRAFT->FINAL TRANSITION IS NOT SUPPORTED: PATCH FINAL is silently ignored, so no API call turns a draft into a finalized document. That is NOT the same as 'API writes cannot move money': an already-finalized document IS writable, as the real form is (it validates fields, not lifecycle), and because the AR balance derives from finalized documents such a write DOES move it. Deliberately unprobed on the shared sandbox — finalizing there would create irreversible book entries. ### Deletion is refused where the real form refuses it DELETE of a customer or an invoice answers the measured InterfaceErrors refusal, and BOTH forms split the message by the row's state: a named customer is pointed at the customer-ledger deletion program and a temporary one at the temporary-customer program, while a DRAFT invoice is pointed at the temporary-invoice deletion program and a FINALIZED one is told it cannot be deleted at all and pointed at the CANCELLATION program instead. Four messages, all verbatim; do not match on one of them. Separately, a well-formed key with no row answers the ordinary OData 400 'A record with the specified key was not found' rather than any InterfaceErrors document, so a DELETE has two different 400 BODIES. DELETE of a customer CONTACT answers the bare 404 (measured). Invoice LINES delete (204). ```bash # answers: 400 curl -u API_USER:API_PASSWORD -X DELETE "https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS('DOCS-EXAMPLE-1')" ``` Response: ```json {"?xml":{"@version":"1.0","@encoding":"utf-8","@standalone":"yes"},"FORM":{"@TYPE":"CUSTOMERS","InterfaceErrors":{"@XmlFormat":"0","text":"שורה 1- למחיקת הלקוח יש להשתמש בתכנית \"מחיקה מכרטסת לקוחות\" (התכנית מופעלת מתפריט \"כרטיסי חשבונות\")."}}} ``` ### $batch (JSON format) executes POST https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/$batch with the JSON body the portal documents (v19.1+): {"requests":[{id, method, url, headers, body}]}. An inner url is either service-root-relative (CUSTOMERS?$top=1, a leading slash is fine) or the FULL published service base plus a path — the base must match exactly, scheme included, so http:// against an https base is refused like any other foreign base. The bare service root IS addressable from inside a batch — a bare slash, the base itself, or the base with its trailing slash all answer the service document (an EMPTY url is not: it answers the missing-method-or-url refusal). Inner METHOD names are case-insensitive. An inner id is echoed with the JSON TYPE you sent (a numeric id comes back a number). Requests run IN ORDER against the same surface with the caller's identity, and the response is {"responses":[{id, status, headers, body}]} (measured shape). At most 100 operations; there is NO rollback (portal). Back-references ($1, $2) never resolve — not with a correct OData dependsOn either — and the refusal depends on where the reference is declared: a $N NOT listed in the item's dependsOn refuses the WHOLE batch with a top-level 400 'Request Id reference [N] in Uri [URL] is not found in effective depends-on-Ids [LIST] of the request.' (LIST is the literal null when there is no dependsOn, otherwise the ids comma-separated), so nothing executes; a $N that IS listed answers that item alone with a 424 'A request dependency failed: N — content-id reference could not be resolved (dependency has no Location mapping)', whose envelope carries only code and message. Scope that precisely: among the refusals the BATCH MACHINERY itself generates — the top-level $N 400, the base-address refusal, missing method or url, an unusable method, a nested $batch, the 100-operation cap — only the 424 is not the full code/message/target/details/innererror envelope — every refusal in that list carries it. It says nothing about what an inner request produces: an inner response carries whatever that resource would have answered directly, so a bare-404 family url still gives an EMPTY body and a rejected write still gives the InterfaceErrors XML-as-JSON. The missing-Content-Type refusal is plain text, and it is not an inner response at all. Only a LEADING $N path segment counts: a $1 inside a $filter value is ordinary text and the request runs. ```bash # answers: 200 curl -u API_USER:API_PASSWORD -X POST -H 'Content-Type: application/json' -d '{"requests":[{"id":"1","method":"GET","url":"CUSTOMERS?$top=1&$select=CUSTNAME"}]}' 'https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/$batch' ``` Response: ```json {"responses":[{"id":"1","status":200,"headers":{"content-type":"application/json; odata.metadata=minimal; odata.streaming=true","odata-version":"4.0"},"body":{"@odata.context":"...","value":[{"CUSTNAME":"100001"}]}}]} ``` - GET /$batch answers 400 '$batch requires POST method'; POST without a Content-Type answers a PLAIN-TEXT 400 body 'The batch request must have a "Content-Type" header.' (no envelope — measured); a MULTIPART body answers 400 'Error reading batch part: multipart: NextPart: EOF' (all measured verbatim). ## Conventions | Topic | Detail | | --- | --- | | Property order | Responses emit properties in METADATA order regardless of $select order (measured). | | Addressing a child row for a write | A SINGLE-KEY child is addressable by its bare key value — AINVOICEITEMS_SUBFORM(1) is KLINE 1. ADDRESSABLE is not WRITABLE: PATCH/DELETE work there only on a form that accepts writes at all, so invoice lines answer 200/204 (the one deleting write) while the children of TINVOICES and PAY answer the API-permission refusal to both verbs, exactly as their parents do. That refusal PRECEDES key resolution, so it arrives whatever key form you send. Their key shapes differ regardless: TPAYMENT2_SUBFORM and PAYITEMS_SUBFORM are single-key (KLINE), while TFNCITEMS_SUBFORM is COMPOSITE (FNCTRANS+KLINE), as its own attribute table shows. A COMPOSITE-KEY child (CUSTPERSONNEL_SUBFORM keyed NAME+FIRM, TFNCITEMS_SUBFORM keyed FNCTRANS+KLINE) is NOT addressable by a bare value in either key position: both answer 404 on the real wire, measured. Contacts are therefore addressed for a PATCH only by the COMPLETE named-pair key (order-insensitive): a PARTIAL key — one naming only NAME or only FIRM — is unaddressable and answers the bare 404 rather than picking a row, because FIRM is shared by every contact of a customer. A COMPLETE key that matches no row answers 400 'A record with the specified key was not found' instead — the two 404/400 answers separate 'that is not an address' from 'no such row'. Key values are matched as TEXT, so a single-key child accepts the bare, quoted or named form alike (KLINE 1, '1' and KLINE=1). And because FIRM carries a customer DESCRIPTION, it usually contains a SPACE: percent-encode it (%20) or curl rejects the URL before sending. DELETE of a contact answers the bare 404 in every key form: contacts are created, read and updated, never deleted. Two traps: a new line takes KLINE = max(existing)+1, so deleting a MIDDLE line leaves a permanent gap while deleting the HIGHEST line frees its number for the next insert (and emptying the invoice restarts at 1) — a stale KLINE can therefore address a different row; and an explicit KLINE in a POST body is IGNORED (the server assigns). FIRM carries the parent's CUSTDES, so RENAMING a customer silently rekeys its contacts — a key captured before the rename no longer resolves. | | Write request and response details | Content-Type: a MISSING one is tolerated on entity writes (the body is still parsed — measured), a non-JSON one is refused with the verbatim MIME message, and $batch alone REQUIRES one. A JSON ARRAY body is refused verbatim on an ENTITY write: 'An unexpected 'StartArray' node was found when reading from the JSON reader. A 'StartObject' node was expected.' Every OTHER body that is not a JSON object — malformed JSON, a bare string, a literal null, trailing junk, or a zero-byte body — answers 'request body is empty' on an entity write and on $batch alike. The message names the SHAPE the parser could not use, not the byte count: read it as 'no usable object here'. Query options are ignored on WRITES generally — a POST carrying $select or duplicated $top values still creates, and returns the full entity — while the same duplicates answer a bare 404 on READS: the query-option rules are read rules. The Location header of a SUBFORM create is informational only: keyed subform items are not readable, so a GET of that exact URL answers the bare 404 (customer and invoice Locations do resolve). A create inside $batch answers its 201 in the batch body WITHOUT a Location header — recover a server-assigned key from the payload. | | Write details an integrator hits | Line defaults, measured: an omitted TQUANT is 1 and an omitted PRICE is 0, and a NEGATIVE quantity is accepted (a negative draft is a legal shape here). A draft with NO lines — created empty or emptied by deleting them — reads totals of 0 with TOTQUANT null, and a create response OMITS the subform key entirely (index it defensively); an $expand of the same row answers an empty array. A duplicate property in a write body takes the LAST occurrence (standard JSON parsing) with no warning. A PATCH body of {} answers 200 and changes nothing, an explicit null CLEARS a column, and a ZERO-BYTE body answers 400 'request body is empty'. An empty string is stored and is DISTINCT from null ($filter=FAX eq '' matches it) on ordinary columns — with two carve-outs: an empty KEY is treated as absent (see Writing data), and a FORM-VALIDATED column stores null rather than '' (REFERENCE '' reads back null and is matched by REFERENCE eq null, not by REFERENCE eq ''), because the empty value short-circuits the lookup instead of passing through it. Writing PAYCODE does not derive PAYDES — set both if you need both. Subform reads come back ordered by key, not by insertion. A nested create is ATOMIC: if a child is rejected, no parent row is left behind. Only the PARENT's STATDES is validated against the instance's status list; a contact's STATDES is stored as given. An explicit IVNUM in an invoice POST is ignored (the server always assigns a draft number) — unlike CUSTNAME, which is honoured and answers 409 when taken. | | Batch response and message details | An inner response's body carries whatever the inner request produced: a JSON object for an entity, a bare NUMBER for /$count, a STRING of XML for $metadata, and the empty STRING where the inner response had no body — type by inner content-type, not a fixed shape. The base-address refusal is 'A batch request url must address a resource under this environment's OData base.' — one message for every way of missing the base. It means the url does not address this environment's OData base at all: a foreign host or environment key, a different scheme, or a path whose leading .. segments climb above the base. The base is matched BYTE-exactly, so even a differently-cased host is foreign. The service ROOT itself IS addressable (the base with or without its trailing slash, or a bare slash), and a dot segment that stays inside the base resolves normally. Percent-encoded dot segments are not decoded into path segments INSIDE a batch, so they address nothing and answer a bare 404 — while on the OUTER url the hosting layer decodes and normalizes them before the API sees the path, so the same sequence resolves. Do not use dot segments to address anything. An inner request missing its url answers the missing-method-or-url message rather than the base refusal, and a body that is not an object answers whatever the inner resource would say about it — an ARRAY draws the entity-write StartArray envelope, a string 'request body is empty'. Duplicate inner ids are echoed as sent (they are not deduplicated, so correlate carefully). The message 'request body is empty' covers more than a zero-byte body: a batch body that parses but carries no requests array, and an inner request whose body is not a JSON object, answer it too. An InterfaceErrors row counter identifies the FORM row, not which child of your payload failed — it reads 'שורה 2-' for any child-level refusal. A percent-encoded OPTION NAME (%24top) is honoured, while a percent-encoded PATH segment (/%24count) is a bare 404 — the encoding rule differs by position. In a key predicate an apostrophe is escaped by DOUBLING it ('O''BRIEN'); a single one answers the bare 404. | | What this surface does NOT offer | There is no optimistic concurrency: entities carry no ETag, If-Match and If-None-Match are ignored, and a PATCH is unconditional last-write-wins — build your own guard if concurrent editors matter. X-HTTP-Method-Override is ignored (a GET stays a GET). $top has no upper bound, so a huge value simply returns everything the result cap allows; only negative and non-integer values are refused. The @odata.context on a write is a DESCRIPTIVE fragment, not a URL: a decoded composite child key can contain spaces, so do not dereference it — use the Location header (for parents) or rebuild the address yourself. | | The environment is not a fresh book | An environment starts from the seeded book described here, but everything anyone writes to it STAYS: the forms refuse API deletion for customers and invoices exactly as the real product does, so a shared or long-lived environment accumulates rows from every integrator who has used it. Do not assume a row count, and do not assume a name is free — create with an explicit key and treat 409 as 'someone got there first'. A write's OWNERLOGIN records who created THAT row, so rows you did not write carry someone else's identity. | | Error precedence: authentication wins | The credential is checked BEFORE routing, before the $batch method check, and before any write-permission or body validation. An unknown path, a GET /$batch, or a POST to a permission-refused form all answer the empty 401 when the credential is missing or wrong — UNDER THE ODATA BASE you will not see a 404, a 400 or a write refusal until you are authenticated. The gate covers the whole /odata prefix, not merely the exact base: a wrong config-file or company segment (…/other.ini/demo, …/demo-typo) answers the empty 401 too, so a 401 there does NOT tell you your credential is good — fix the credential first, then the path, because until you authenticate both mistakes look identical. Only paths outside /odata — the tenant root, unknown non-OData paths — answer their bare 404 unauthenticated, carrying nothing to protect. (The real instance gates its own wrong-company paths the same way.) Fix auth first; every other diagnosis downstream of it is unreliable. One more ordering worth knowing: on a keyed write the KEY is resolved before the body is parsed, so a malformed body against a missing key answers 'A record with the specified key was not found' rather than a body complaint. | | Published-document versioning | This document is generated from the deployed build, so during a deployment the docs URL can briefly serve the previous build's contract. If a documented behaviour and the wire disagree, re-fetch the document before treating the difference as a defect — and note the x-deployment-id response header, which changes when the build does — it is emitted on 2xx responses only, so capture it from a successful call. | | Content negotiation is not honoured | The response media type is fixed by the ENDPOINT, never by your Accept header: Accept, OData-Version and Prefer are silently ignored (measured — Accept: application/xml on an entity set still answered JSON). Entity and collection reads are application/json (odata.metadata=minimal — the parameter phrasing varies by backend, a ledgered variance). Three endpoints are not JSON, and asking for JSON will not make them so: /$metadata and GetMetadataFor(entity='X') answer application/xml (EDMX), and /$count answers text/plain. One refusal is plain text too — a POST /$batch with no Content-Type header. | | Sparse rows | Every declared property is emitted on every row, null where the record carries no value — exactly how real rows read. | | Document lifecycle | Draft (T-number, FINAL null) → Final (book number, FINAL 'Y'). Cancellation adds a reversing row with negative totals beside the surviving original — the reversing row carries its OWN document number (IN254000012 reverses IN254000011), so never join a reversal to its original by IVNUM; the original keeps STATDES 'Final' while the reversal reads 'Canceled'. | | Case sensitivity | Per the developer portal, requests are case sensitive: forms and fields are UPPERCASE and must be matched exactly. This simulator enforces that — a lowercase entity set answers the bare 404, a lowercase field the unknown-property 400. (The shared sandbox was observed to TOLERATE lowercase on some backend versions; the portal's documented contract is what a portable client must assume, and what we serve.) Query OPTION NAMES are the measured exception: $TOP=5, $ToP=5 and $top=5 are all honoured (six repeats each on the real wire, also $SELECT/$FILTER/$EXPAND/$ORDERBY) — option names are case-INsensitive, and so is the GRAMMAR inside an option value — the $orderby direction word (desc/DESC/Desc), the $filter comparison operators (eq/EQ/Eq), the and/or connectives, the null literal, and the T and Z designators in a $since timestamp. What stays case-SENSITIVE is the DATA: property names ($select=custname answers 'Could not find a property named custname'), entity-set names (/customers is a bare 404), and string literals you compare against. Basic-auth USERNAMES are case-sensitive (an uppercased username answers the empty 401 — measured on both wires). | | Result limits in the real product | Real Priority caps collection results by the MAXFORMLINES system constant (MAXAPILINES, default 2,000, from v25.1) — measured: an uncapped CUSTOMERS pull on the official sandbox returned exactly 2,000 rows. This simulator's seeded book is far below any cap, so no cap is simulated; page with $top/$skip regardless, as you would against the real product. | | /$count | GET /$count answers the matching-entity count as a PLAIN-TEXT number, and HONOURS $filter and $since (measured on the real wire: 856 unfiltered vs 133 filtered); $top/$skip do not apply. $orderby is meaningless to a count but is still VALIDATED — a malformed one is refused 400 exactly as on a collection read. The path must use a literal $ — a percent-encoded /%24count answers a bare 404. On the shared sandbox this endpoint is one of the ledgered backend-version coins (number on one version, a 500 cast-error envelope on the other); this simulator serves the number. | | HEAD and OPTIONS | On entity-set-BACKED paths (collection, item, subform, and /$count) both answer a bare 404 (measured on the newer sandbox backend; the other draw answers 501 — a ledgered coin). The service root and $metadata answer them like GET — 200, measured six times each on the real wire. Function imports flip 404/200 by backend draw there (ledgered); this simulator answers them like GET. Do not preflight with any of them; issue the GET. | | Methods and the write verbs | POST/PATCH/DELETE are REAL on the writable forms (CUSTOMERS, AINVOICES — see the writing-data section); on TINVOICES, PAY and ACCOUNTS_RECEIVABLE every write verb answers the measured API-permission refusal verbatim, before any body parsing. PUT is a measured oddity reproduced as-is: PUT of an EXISTING record answers a bare 404, PUT of a missing one 400 'A record with the specified key was not found' — do not use PUT. The service root, $metadata and function imports answer every REGISTERED method like GET (POST /$metadata returned the EDMX six times out of six on the real wire; POST on a function import is a 404/200 backend coin there — this simulator answers like GET). On form paths, registered unusual methods like PROPFIND never reach the real product — its hosting edge refuses them with plain 403/405 HTML pages (measured six times) — and this simulator answers them with its bare 404 rather than impersonating an edge. TRACE specifically is refused by HOSTING infrastructure on BOTH deployments (405, empty or HTML body) before any API code runs, and unregistered method names may draw an empty 501 from the runtime — even on the root. | | Path tolerances | A trailing slash on a collection is tolerated (measured). A DUPLICATED honoured query option — $top, $skip, $filter, $select, $orderby, $expand or $since, in any letter case — answers a bare 404 (measured for $top five times, and for $filter/$select/$orderby on the same backend draw; the OTHER sandbox backend takes the last value instead, a ledgered variance, so never send duplicates). A repeat with an EMPTY value ($top=1&$top) does not count as a duplicate — the valued option is honoured (measured). $top=0 and $skip=0 are no-ops; negative or non-integer values are refused with the Invalid-value 400 (see the $top parameter row). Assorted benign tolerances (measured): a trailing comma in $select — but NOT in $orderby, where it is refused as an unnamed property — an EMPTY-valued option ($filter=), trailing slashes on /$count and on ITEM reads, %20 inside a key predicate, and a duplicated child NAME inside one $expand (deduped — the duplicate-option 404 is about repeated options, not values) are all accepted. An UNQUOTED key (CUSTOMERS(100001)) is in the bare-404 family, and so is a predicate naming an extra or duplicated key part. The NAMED form works on a single-key set too (CUSTOMERS(CUSTNAME='100001')), and composite keys are order-insensitive everywhere, not only on children. Function imports accept the empty-parens call form (GetLoginName() = GetLoginName). | | Function imports | Five utility functions sit beside the entity sets in the service document, callable as plain GET paths, and $metadata declares them (Function elements with Edm.String returns plus FunctionImports, GetMetadataFor included with its entity parameter — the real document's shape). GetPriorityVersion, GetODataVersion and GetBinVersion answer { "@odata.context": "...$metadata#Edm.String", "value": "" } — the values identify the instance, not a contract. GetTenantDetails answers BARE JSON with no @odata.context: { "tenantID": "", "hosting": true }. GetLoginName answers the #Edm.String shape carrying the authenticated API username. All require Basic auth like everything else. | | Per-entity metadata | GET https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/GetMetadataFor(entity='CUSTOMERS') (v25.0+) returns EDMX scoped to the entity, exactly like the real product; %27-encoded quotes around the parameter are accepted too (measured). An unknown entity answers the real product's own 404 envelope verbatim: netprest return no data for X (the majority sandbox draw — one backend version answers a 500 'XML decode: EOF' envelope instead, a ledgered variance). Malformed forms (missing quotes, bare GetMetadataFor) answer the bare 404. | | Nested $expand options | The separator inside $expand=CHILD(...) is ';', never ','. A comma runs the rest of the clause into the current option's value and is refused 400 with that option's own error — ($top=1,$select=NAME) answers 'Top option must be a non-negative integer, it is set to '1,$select=NAME' instead.'; ($select=NAME,$top=1) answers 'Found system token '$top' in select or expand clause 'NAME,$top=1'.' (both measured verbatim, six repeats). Nested $top must be a non-negative INTEGER: 0 means no limit (the full child set — measured), a positive value truncates, anything else is refused with the Top-option envelope — note the DIFFERENT envelope from top-level $top's Invalid-value message; both refuse. Nested $skip is honoured; a non-integer OR NEGATIVE nested $skip is refused with the symmetric envelope 'Skip option must be a non-negative integer, it is set to 'abc' instead.' (the strict draws of ledgered coins — one backend version leaks 'Invalid query options: strconv.Atoi: ...' for non-integers and ignores negatives). Nested $orderby and $filter are honoured against the child type. DUPLICATED nested options take the LAST value (measured six times — ($top=1;$top=2) truncates to 2), unlike top-level duplicates, which answer the bare 404. A nested $expand is refused 400 — the could-not-find envelope against the CHILD type for an unknown name, the not-a-navigation envelope for a plain child property (subforms publish no further navigations). An unknown property in a nested $select is refused 400 with the instance's own XML-generation message IN THE INSTANCE LANGUAGE (the reference instance is Hebrew-localized; emitted verbatim) — NOT the could-not-find envelope. Unknown nested $-options ($count=true) are silently ignored. One sandbox backend family phrases these refusals as 'Invalid query options: ...' instead (a ledgered variance); the option-specific messages above are the majority family, and what this simulator serves. | | Item reads ignore list options | On an ITEM read (a keyed path), $select and $expand are honoured; $filter, $top and $skip are NOT EVEN PARSED — measured: an item read still answers the entity with a $filter that excludes it, with an unknown-property or function $filter that would 400/501 on a collection read, and with $top=-1 (three repeats each). $orderby IS still validated (a garbage direction answers its 400). So is every option NESTED inside $expand: a nested $filter naming an unknown child property, a nested typed mismatch, a nested $top=-1 or $skip=abc all answer 400 against the CHILD type, and a nested $filter FUNCTION answers 501 — on an item read exactly as on a collection. The rule is not 'item reads validate less', it is 'the TOP-LEVEL $filter/$top/$skip are not parsed on a keyed path'. Duplicated options answer the bare 404 everywhere. Do not rely on a filter to guard an item read. | | Subform addressing | A subform is addressable as a path segment — CUSTOMERS('X')/CUSTPERSONNEL_SUBFORM — and supports the query options against the CHILD type, including /$count (a plain-text number honouring $filter; on the shared sandbox this is the same ledgered /$count coin, answering a 500 cast-error envelope on the other draw). A KEYED subform item — CUSTPERSONNEL_SUBFORM(NAME='x',FIRM=1) — answers a bare 404: a ledgered coin (two of six sandbox draws served the entity; the committed draw here does not — filter the subform collection instead). A PROPERTY path segment (CUSTOMERS('X')/CUSTNAME) answers a bare 404 (six consistent draws; a rare backend answered a 400 'Invalid OData path' envelope once — ledgered); project with $select instead. | | Nulls in filters and sorts | $orderby places NULLS FIRST ascending and LAST descending, and an empty string sorts above null descending — page a sparse column with a tie-breaker if the boundary matters. In $filter, a comparison against a VALUE excludes rows where the property is null — eq/gt/ge/lt/le all skip them (comparing against the null LITERAL is different, and covered below). ne is the exception: a row whose property is NULL matches 'X ne value' (measured on the real wire — a filter on an all-null column returned every row for ne and none for eq). With the sparse-row rule (every property emitted, null where unpopulated), an ne filter can therefore return far more rows than its complement excludes. eq null and ne null work as expected. | | $filter operand forms | The right operand may be ANOTHER PROPERTY — TOTPRICE eq DISPRICE compares the two row values (measured honoured; one sandbox backend draw matched nothing — ledgered). Both sides must be in the same type family, like literals. A NAVIGATION on either side is refused 400 'The operand for a binary operator 'Equal' is not a single value. Binary operators require both operands to be single values.' (measured; another backend draw silently ignores the filter — the refusal is committed). The 'not' operator is a TRAP: not (...) parses and silently matches NOTHING (measured three times — neither honoured nor refused); express negation with ne and De Morgan instead. The OData 'in' operator never reaches the real product — its hosting edge refuses the pattern with a 403 HTML page (measured); this simulator answers the grammar 400. A mismatched parenthesis answers 'Invalid query options: parse error. Mismatched parenthesis.' verbatim. | | $batch executes (JSON format) | POST /$batch with the portal's JSON body (v19.1+) EXECUTES: inner requests run in order against this same surface with the caller's identity, and the response is {"responses":[{id,status,headers,body}]} — the measured shape. Inner urls may be absolute or service-root-relative; at most 100 operations (the portal's limit) — exceeding it refuses the WHOLE call with a top-level 400 'Batch commands are limited to 100 operations in one batch call.'; and the cap cannot be recursed around, because a NESTED $batch is refused per item. Refusals divide into two kinds, and the difference decides whether earlier writes survive. WHOLE-CALL (no responses array, nothing executes): anything wrong with the batch REQUEST ITSELF — a non-POST method, a missing or unusable Content-Type, a body that is not an object carrying requests, the 100-operation cap, and a $N back-reference not listed in its item's dependsOn. PER-ITEM (200 outer, siblings still answer): anything wrong with an individual inner request — an unusable method, a nested $batch, a foreign base, a missing method or url, and every refusal the addressed resource itself produces. An inner url must address THIS environment's OData base: a foreign host or environment key is refused per item rather than quietly answering with your data. There is NO rollback (portal): earlier operations persist when a later one fails, so a batch is not a transaction. The ONE case where earlier writes do not happen is a $N back-reference that is NOT listed in its item's dependsOn: that is detected before any item runs and refuses the whole call, so nothing executes. A $N that IS listed is refused per item (424) like any other failing item — the batch still runs, and earlier writes in it DO land. Failures are contained to their item — an unusable inner method fails only that request and its siblings still answer. Micro-contract: a request missing method or url answers 'Each batch request needs a method and a url.'; an inner method outside GET/POST/PATCH/PUT/DELETE/HEAD/OPTIONS answers a per-item 501 'Not implemented: METHOD PATH' — the method echoed as you sent it and the path WITHOUT its query string (the real instance coins between this and a bare 404; the informative draw is served here, and PROPFIND/TRACE/CONNECT are all in this family inside a batch, whatever they do on a direct request); a nested batch 'A batch request may not contain another $batch.'; a $N back-reference is refused as described under $batch above — whole-batch 400 when it is not in dependsOn, per-item 424 when it is; a missing id comes back as the KEY id with an empty-string value, not omitted; an empty requests array answers 200 with an empty responses array; an inner HEAD follows the same path split as a direct one — a bare 404 on entity-set-backed paths (collection, item, subform, /$count), and on the service root, $metadata and the function imports the FULL body its GET would produce, where a direct HEAD would have given you headers only. So a batched HEAD is never a header-only probe: it either fails or hands you the whole payload; a batch create's 201 carries NO Location header (read the server-assigned key from the payload); an inner response with no body carries body as the empty STRING; and an inner request's headers object is accepted but INERT — it cannot change the identity the batch already authenticated as, so do not try to switch credentials per item. A body on a GET or HEAD item is ignored rather than refused, so a client that serializes `body` unconditionally still reads normally. Assorted batch tolerances: a doubled slash, a trailing slash on /$batch, query options on the /$batch url itself, and a Content-Type carrying parameters (charset, odata.metadata) are all accepted; a duplicate requests key takes the last. A #fragment is NOT stripped — in path position it makes the url address nothing (bare 404), and it only survives inside a query value, where it lands in an ignored option. Whitespace in the PATH of an inner url is a bare 404 — leading whitespace, or trailing whitespace when the url has no query string. Trailing whitespace AFTER a query string is not: it lands inside the last option's VALUE, which the option parser tolerates, so the request runs normally (measured on the real instance too). The measured refusals stand verbatim: GET → '$batch requires POST method'; POST without a Content-Type → the PLAIN-TEXT body 'The batch request must have a "Content-Type" header.' (one backend draw serves the same text for GET — ledgered phrasing coin); a MULTIPART content type → 'Error reading batch part: multipart: NextPart: EOF' (this simulator never parses a multipart batch), and any OTHER non-JSON content type → the same MIME refusal an entity write answers. | | Writing data — what a write may and may not do | POST creates DRAFTS with server-assigned temporary numbers (customers T-numbered when unnamed with STATDES 'Potential', 'Active' when named; invoices always T-numbered, STATDES 'Draft', FINAL null) — every write behaviour here was measured on the real wire, envelopes verbatim. Server fills OWNERLOGIN (the authenticated identity, PATs included), CREATEDDATE/STATUSDATE/IVDATE as date-only midnight Z, the CUST auto-unique, CDES from the customer, and the amount identity (plus TOTQUANT) from lines. PATCH applies WRITABLE columns only: server-owned columns (keys, computed amounts, INACTIVEFLAG, an invoice's FINAL/STATDES) are SILENTLY IGNORED while the response still answers 200 — read back to confirm, this is the real form engine's measured behaviour. Values are coerced to the COLUMN, not preserved as sent (measured): an Int column ROUNDS a fractional literal half toward +∞ (1.5 → 2, −1.5 → −1), while a Decimal column rounds to its declared SCALE half AWAY FROM ZERO (PRICE p13s2: 10.987654 → 10.99, 0.125 → 0.13, −0.125 → −0.13) — the two rules differ on negatives, so do not carry one across, and a string column TRUNCATES at MaxLength — counted in UTF-16 code units; when the cut would fall BETWEEN the halves of a surrogate pair the orphaned half is dropped too, so a truncated value is always well-formed text (and one unit shorter than the limit). KEY columns are the exception: a NON-EMPTY key is stored as given, so an over-long key is preserved and only the full value addresses the row. An EMPTY key is not stored at all — CUSTNAME '' is treated as ABSENT and takes the unnamed-create path, answering 201 with a server-assigned T-number and STATDES 'Potential' (measured on the real instance too). That is a trap worth guarding in your client: a serializer that emits '' for an unset field silently creates a temporary customer instead of drawing the missing-key refusal that an empty BODY draws. A quantity on the whole-unit 'ea' must be an integer (a fractional TQUANT answers the verbatim whole-value refusal). A Decimal's SCALE is enforced but its PRECISION is not, and an Int column is float-backed: values beyond 2^53 lose exactness and an extreme magnitude is stored as given and serializes in exponent form (1e+30) rather than being rounded — it is already past the column's precision. Keep amounts and identifiers inside their declared domains. Read back rather than assuming your value survived. A PATCH with an empty body answers 200 and changes nothing; an explicit null CLEARS a column. FINALIZED DOCUMENTS ARE NOT PROTECTED: an invoice with FINAL 'Y' accepts writable-column PATCHes and line writes exactly as the real form does (measured — the form validates fields, not lifecycle), and because the AR balance derives from finalized documents, such a write DOES move it. What is unsupported is the TRANSITION: no API call turns a draft into a finalized document (PATCH FINAL is ignored), so balances move only when you edit something already final. | | Backend-version variance | Eighteen sandbox surfaces answer identical requests differently by backend version (filter functions, /$count incl. subform counts, GetLoginName shape and its non-GET methods, unknown-property filters, TYPED filter literals — the incompatible-types 400 vs silent coercion, a NAVIGATION in $filter — the not-single-value 400 vs silently ignored, property-vs-property comparisons — honoured vs matching nothing, partial-key reads, lowercase entity sets, HEAD/OPTIONS on entity sets, duplicated query options, keyed subform items, negative top-level $top/$skip and negative nested $skip, nested $top=-1, GetMetadataFor on an unknown entity, the non-integer nested-$skip message, property path segments, and refusal-message phrasing generally). This simulator commits to one coherent version; the conformance ledger records each choice and the evidence. | ## Limitations - POST creates DRAFTS, and the draft->final TRANSITION is not supported (PATCH FINAL is silently ignored). An already-finalized document is still WRITABLE, though, and because the AR balance derives from finalized documents such a write moves the balance — do not treat the API as incapable of touching money. Deliberately unprobed — finalizing on the shared reference sandbox would create irreversible book entries. - This book publishes no parts catalog: PARTNAME on invoice lines is accepted as given, where the real product validates it against its parts table (measured refusal ledgered). - $batch back-references ($1, $2, ...) never resolve, and the refusal takes one of two shapes depending on the item's dependsOn — a whole-batch 400 that runs nothing, or a per-item 424. See the $batch section for the exact messages and which writes survive each. - This simulator's hosting edge may refuse requests carrying certain default AUTOMATED User-Agent strings (for example Python-urllib) with a plain 403 before the API is reached. That is a hosting artifact, not Priority behaviour — the official sandbox serves such clients normally. Send an explicit User-Agent header from stdlib HTTP clients. - A request whose environment key does not exist answers a vendor-neutral 404 problem document (application/problem+json, code SIM-1000) BEFORE any authentication — the key routes requests, it is not a credential. Everything under a VALID key behaves as this document describes, including the tenant root and unknown paths (bare 404). - OAuth2 via the External ID module is not implemented (Basic and PAT are). The portal notes Basic is unavailable on real instances where External ID is enabled. - Entity sets beyond the five above answer a bare 404 — the real instance publishes 1,739; this simulator publishes exactly what it serves. - String functions in $filter answer 501 (see the variance note). - The AR balance derivation is simulator-defined and documented; the real instance's could not be verified from the shared sandbox. ## Capability matrix Every capability, with its support status. `not_supported` means exactly that — do not build against it. | Capability | Protocol | Resource | Operations | Auth | Status | Notes | | --- | --- | --- | --- | --- | --- | --- | | Service document + $metadata (EDMX, real property names/types) | REST | `/, /$metadata` | GET | Basic | **supported** | | | Customers with contact subform | REST | `/CUSTOMERS (+CUSTPERSONNEL_SUBFORM)` | GET list, item, subform, $expand | Basic | **supported** | | | Sales invoices with lines | REST | `/AINVOICES (+AINVOICEITEMS_SUBFORM)` | GET list, item, subform, $expand | Basic | **supported** | | | Receipts with payment means and applications (partial/unapplied) | REST | `/TINVOICES (+TPAYMENT2_SUBFORM, TFNCITEMS_SUBFORM)` | GET list, item, subforms, $expand | Basic | **supported** | | | Payment terms | REST | `/PAY (+PAYITEMS_SUBFORM — empty in this single-payment book)` | GET list, item, subform, $expand | Basic | **supported** | | | AR balances (computed; derivation documented) | REST | `/ACCOUNTS_RECEIVABLE` | GET list, item | Basic | **supported** | | | Utility function imports | REST | `GetPriorityVersion, GetODataVersion, GetBinVersion, GetTenantDetails, GetLoginName` | GET | Basic | **supported** | | | Customer writes (drafts, contacts, nested create) | REST | `/CUSTOMERS (+CUSTPERSONNEL_SUBFORM)` | POST, PATCH; DELETE refused by the form (contacts: bare 404) | Basic / PAT | **supported** | Measured contract: a supplied CUSTNAME is honoured (Active) and an absent or empty one draws a T-number (Potential); server fills; InterfaceErrors refusals verbatim. | | Invoice draft writes with lines | REST | `/AINVOICES (+AINVOICEITEMS_SUBFORM)` | POST (nested lines), PATCH, line POST/PATCH/DELETE(204); header/draft DELETE refused | Basic / PAT | **supported** | POST creates DRAFTS and no API call finalizes one (FINAL is silently ignored) — but an ALREADY-finalized invoice is writable, and such a write moves the AR balance. Totals recompute from lines. | | Writes on receipts, terms, balances | REST | `/TINVOICES, /PAY, /ACCOUNTS_RECEIVABLE` | — | Basic / PAT | **not_supported** | The measured API-permission refusal, verbatim, on every write verb. | | $batch (JSON format) | REST | `/$batch` | POST (≤100 inner requests, no rollback, no $N refs) | Basic / PAT | **supported** | | | Personal Access Tokens | REST | `every path (Basic: token as username, password 'PAT')` | — | PAT | **supported** | | | SOAP | SOAP | `—` | — | — | **not_supported** | Priority Cloud's integration surface is OData; there is no SOAP service to simulate. | ## REST resources ### `CUSTOMERS` Customer master records (117 properties, the full real form). Payment terms appear as PAYCODE/PAYDES on the customer. Base path: `https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS` #### Operations | Method | Path | Status | Description | | --- | --- | --- | --- | | GET | `https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS` | supported | Collection read with the query options above. $count, $search, $format, unknown $-options and non-$ parameters are SILENTLY IGNORED (measured) — rows come back unaffected. This is Priority's behaviour, not an omission. | | GET | `https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS('')` | supported | Item read: $entity context, properties at TOP LEVEL (no value wrapper). $select applies and so does $expand; LIST options on an item read ($filter, $top) are SILENTLY IGNORED — measured, an item read with a $filter that excludes the entity still returns it. | | GET | `https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS('')/CUSTPERSONNEL_SUBFORM` | supported | The customer's contact persons. Key (NAME, FIRM) where FIRM carries the parent customer's DESCRIPTION (CUSTDES) — measured on the real wire, both on seeded rows and in a write's own Location header. Also reachable inline via $expand=CUSTPERSONNEL_SUBFORM. An inline child carries no envelope of its own and is the COMPLETE child set unless narrowed by nested options ($top/$skip/$orderby/$select/$filter). The path form supports the query options against the CHILD type, and ('')/CUSTPERSONNEL_SUBFORM/$count answers the child count as a plain-text number honouring $filter. A KEYED subform item (CUSTPERSONNEL_SUBFORM(...)) is NOT addressable for READS — bare 404. WRITES do address child items here: POST ('')/CUSTPERSONNEL_SUBFORM creates one, and PATCH ('')/CUSTPERSONNEL_SUBFORM() updates it — DELETE answers the bare 404: this child is never deleted through the API. See the writing-data section for the payload contract. | | POST | `https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS` | supported | Creates a record. A key you SUPPLY is honoured — the row lands under your CUSTNAME with STATDES 'Active', and a name already taken answers 409. Supply NO key (or an empty one, which counts as none) and the form assigns a temporary T-number with STATDES 'Potential'. The response is 201 with the FULL entity — server-filled values included — and a Location header with quotes percent-encoded. Children may ride in the same POST as subform arrays and are echoed back. See the writing-data section for the exact contract and refusals. | | PATCH | `https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS('')` | supported | Applies WRITABLE columns and answers 200 with the full entity, while a FORM-VALIDATED column refuses the whole write with a 400 instead (which columns those are differs per form — see the writing-data section). Server-owned columns in the payload are SILENTLY IGNORED (measured — the response is still 200): read back to confirm. Unknown properties and wrong JSON types are refused. | | DELETE | `https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS('')` | not_supported | The form refuses API deletion, with a DIFFERENT message per row state (named vs temporary customer; draft invoice vs finalized, where the message points at the CANCELLATION program because a final document cannot be deleted at all), and a well-formed key with no row answers the ordinary OData 400 'A record with the specified key was not found' instead of any InterfaceErrors document — the measured InterfaceErrors message, verbatim. Subform LINES are the exception where the writing-data section says so. | ##### GET https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS | Status | Meaning | | --- | --- | | 200 | OK — { "@odata.context": ..., "value": [...] } | | 401 | Missing or wrong credential — EMPTY body, WWW-Authenticate: Basic. Checked BEFORE routing, so it precedes every other code here. | | 501 | A $filter FUNCTION (contains, startswith, tolower, ...) — 'Function "X" is not supported'. Reachable wherever a $filter is PARSED: collections, subforms, /$count, and inside a NESTED $expand option on any read, item reads included. | | 400 | An unknown property in $select/$filter/$orderby, a typed-literal mismatch, or an invalid $top/$skip value — $orderby is validated even where the option is otherwise ignored | | 404 | A DUPLICATED honoured query option — bare 404, EMPTY body (distinct from the envelope 404 of a key that does not resolve) | Request: ```bash curl -u API_USER:API_PASSWORD 'https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS?$top=5' ``` ##### GET https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS('') | Status | Meaning | | --- | --- | | 200 | OK — $entity payload | | 401 | Missing or wrong credential — EMPTY body, WWW-Authenticate: Basic. Checked BEFORE routing, so it precedes every other code here. | | 400 | An unknown property in $select, a bad $orderby, or any invalid NESTED option inside $expand (validated against the CHILD type: unknown property, typed mismatch, bad $top/$skip). A TOP-LEVEL $filter/$top/$skip is not parsed here, so its invalid values answer 200 with the entity. | | 404 | A DUPLICATED honoured query option, or a key form in the bare-404 family — EMPTY body, distinct from the envelope 404 below. | | 501 | A $filter FUNCTION inside a NESTED $expand option — 'Function "X" is not supported'. A top-level $filter is not parsed on an item read, so a function THERE answers 200. | | 404 | Well-formed key, no match: the ENVELOPE 404 'The specified entity was not found'. Missing key parts: bare 404, empty body. | ##### GET https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS('')/CUSTPERSONNEL_SUBFORM | Status | Meaning | | --- | --- | | 200 | OK — collection payload | | 401 | Missing or wrong credential — EMPTY body, WWW-Authenticate: Basic. Checked BEFORE routing, so it precedes every other code here. | | 501 | A $filter FUNCTION (contains, startswith, tolower, ...) — 'Function "X" is not supported'. Reachable wherever a $filter is PARSED: collections, subforms, /$count, and inside a NESTED $expand option on any read, item reads included. | | 400 | An unknown property in $select/$filter/$orderby, a typed-literal mismatch, or an invalid $top/$skip value — $orderby is validated even where the option is otherwise ignored | | 404 | A DUPLICATED honoured query option — bare 404, EMPTY body (distinct from the envelope 404 of a key that does not resolve) | | 404 | The PARENT key does not resolve — envelope 404 | ##### POST https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS | Status | Meaning | | --- | --- | | 201 | Created — full entity payload, Location header | | 401 | Missing or wrong credential — EMPTY body, WWW-Authenticate: Basic. Checked BEFORE routing, so it precedes every other code here. | | 400 | Form validation refused: the InterfaceErrors document (instance language), or a property/type refusal in the OData envelope | | 409 | A record with the specified key already exists | ##### PATCH https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS('') | Status | Meaning | | --- | --- | | 200 | OK — full entity payload | | 401 | Missing or wrong credential — EMPTY body, WWW-Authenticate: Basic. Checked BEFORE routing, so it precedes every other code here. | | 404 | The address is in the bare-404 family (unquoted key, an extra key part, missing parts of a composite key) — bare 404, EMPTY body, before any body parsing. | | 400 | Unknown property / type mismatch / form refusal, or 'A record with the specified key was not found' | ##### DELETE https://erplab.cloud/sim/{environmentKey}/odata/Priority/tabula.ini/demo/CUSTOMERS('') | Status | Meaning | | --- | --- | | 400 | InterfaceErrors: use the form's deletion program | | 401 | Missing or wrong credential — EMPTY body, WWW-Authenticate: Basic. Checked BEFORE routing, so it precedes every other code here. | | 404 | The address is in the bare-404 family (unquoted key, an extra key part, missing parts of a composite key) — bare 404, EMPTY body, before any body parsing. | #### Query parameters | Parameter | Description | Example | | --- | --- | --- | | `$select` | Comma-separated property projection. Response properties keep METADATA order, not $select order, while the CONTEXT fragment echoes the order you sent (with duplicates deduped), and $select=* is honoured — the full property set with a (*) context (all measured). PLAIN properties only: naming a subform navigation in $select is refused 400 with the instance-language XML-generation message (measured) — embed subforms with $expand instead. | `$select=CUSTNAME` | | `$filter` | eq, ne, gt, ge, lt, le with and/or and parentheses; string literals in single quotes, dates bare ISO-8601, null bare. LITERALS ARE TYPED: a numeric property takes a bare numeric literal, a string property a quoted one, a date property a bare ISO date — a family mismatch (COMMISSION gt '500', CUSTNAME eq 5) is refused 400 'A binary operator with incompatible types was detected. Found operand types ... for operator kind ...' (the strict draw of a measured backend variance; the other backend silently coerces or matches nothing — never rely on that). FUNCTIONS (contains, startswith, ...) answer 501 here — the shared sandbox answers them non-deterministically by backend version, so this simulator serves the one refusal an integrator can code against anywhere. An unknown PROPERTY is refused 400 naming it. | `$filter=CUSTNAME eq '100001'` | | `$orderby` | Field asc\|desc, comma-separated for multi-key. The direction word must be asc or desc: anything else ($orderby=CUSTNAME sideways) is refused 400 on every measured draw — 'Syntax error at position N in '