Skip to content
Book a demo
Porosi API · Permissioned access

Connect the systems around your order. Access starts with Porosi approval.

Porosi API access is private and tenant-scoped. Contact us with the system, data and actions you need; credentials and production permission are issued only after technical review.

Request API permission Email [email protected]
  • Public sign-upNot available
  • Access scopeAgreed per tenant
  • CredentialsAfter approval
01IntegrationWarehouse ERP
02Requested objectsOrders · Products
03Requested actionRead reviewed records
04TenantSupplier workspace

Permission before credentials. Scope before production data.

  1. Contact
  2. Review
  3. Scope
  4. Validate
  5. Approve
01 Access comes first

There is no public API key to copy. You must contact Porosi for permission.

The API is not an anonymous or self-service data surface. We first establish who is integrating, which tenant is involved, what information is required and whether each proposed action should be read-only or write-enabled.

  1. 01
    Identify the organisation and system.

    Tell us who will operate the integration, which supplier workspace is involved and the system that needs to connect.

  2. 02
    Define the minimum data required.

    List the customer, product, price, order, stock or delivery information needed to complete the workflow.

  3. 03
    Separate read from write.

    Reading a reviewed record and changing a live operational record are different permissions and are assessed separately.

  4. 04
    Prove the route before production.

    Credentials, documentation and production access follow approval and the agreed validation plan—not a form submission.

The access ruleNo anonymous access. No public credential generator. No production permission by assumption.

Request access by email
02 Define the object boundary

Ask for the records the workflow needs. Nothing broader.

These examples describe common wholesale data conversations, not a public endpoint contract. Available fields, actions and response shapes are confirmed only after Porosi approves the integration scope.

Illustrative object

Orders need a stable commercial meaning.

A downstream system may need the customer reference, delivery date, final lines, supplier review state and order total. Whether the integration can read drafts, reviewed records or write changes is part of the permission decision.

  • Customer and delivery context
  • Products, units, quantities and prices
  • Review and fulfilment state

Illustrative response shape

{
  "order_reference": "POR03849989",
  "state": "reviewed",
  "customer_reference": "ACC-1042",
  "delivery_date": "approved-date",
  "lines": [
    { "sku": "443", "quantity": 2 }
  ]
}

Example only. The approved contract may differ.

03 Approval lifecycle

Move from business need to production permission in deliberate stages.

API work affects live supplier operations and customer data. Porosi therefore reviews the workflow, tenant, objects, actions, authentication and expected volume before any production route is agreed.

Prepare an access request
01
Contact

Describe the operational outcome.

Tell us which system is connecting, which supplier tenant is involved and what the integration should accomplish.

Required
02
Technical review

Map the systems and data owners.

Identify sources of truth, object identities, review checkpoints, personal data and failure responsibilities.

Review
03
Permission design

Agree the smallest useful access.

Separate read and write actions, bind the route to the relevant tenant and define expected request volume.

Scope
04
Validation

Prove normal and exceptional cases.

Test representative orders, missing mappings, retries, duplicate requests and the operational recovery path.

Validate
05
Production

Issue access after approval.

Porosi supplies the agreed onboarding details and production permission only when the technical route is accepted.

Approve
06
Ongoing control

Monitor, rotate and revisit access.

Credentials must be protected. Limits, authentication requirements and access can change to keep the service safe.

Operate
04 Operational records

The API should reflect the product your team actually operates. Not a disconnected shadow database.

Products in Porosi carry supplier identity, units, categories, pricing levels, availability and commercial flags. Approved API work starts by deciding which part of that operational record another system genuinely needs.

See the permission boundaries
Porosi products workspace showing supplier SKUs, product names, categories, units, pricing levels, availability and commercial flags
Real Porosi product interface

Shown at its natural aspect ratio and cropped only to focus on the supplier-owned product data.

  1. 01Identity

    SKU, product, category and unit.

  2. 02Commercial context

    Pricing levels and customer-specific decisions.

  3. 03Operational state

    Availability, flags and warehouse context.

  4. 04Permission boundary

    Only the approved fields and actions leave the tenant context.

05 Security is part of the contract

Permission is not one switch. It is a chain of boundaries.

Production access is designed around an approved integration identity, tenant context, object boundary and set of actions. Credentials must remain server-side and access can be limited, rotated or revoked.

01
WhoApproved integration

The organisation and operating system are known before access is issued.

02
WhereTenant context

The integration is tied to the relevant supplier workspace rather than a global data surface.

03
WhatObject boundary

Orders, products, customers, inventory or other data are considered separately.

04
HowRead and write actions

Each action must serve the approved workflow; write access is never assumed from read access.

05
How muchVolume and service controls

Rate limits, quotas, retries and operational responsibilities are agreed for a safe production route.

06
How longRotation and revocation

Credentials and permissions remain controllable throughout the integration lifecycle.

Credential ruleDo not send secrets through public forms, client-side code, screenshots or source control. Porosi provides the approved credential-handling instructions during onboarding.

06 Request API permission

Give us enough context to make the first technical conversation useful.

Provide your contact details, then choose the system type, data objects and access direction you expect. The form sends the brief to Porosi for review; it does not create credentials or grant access.

API access contact[email protected]+44 07927 994619
API access request briefPorosi approval required
01 Your contact details
02 System type
03 Data objects
04 Expected access
Prepared request

ERP · Orders, Products · Read

Sending the request begins a review. It does not grant API permission or create credentials.

07 API questions

What technical and operations teams should establish before access.

API access is a controlled integration decision. The fastest route is to bring the real systems, objects, actions, expected volume and operational owner into the first conversation.

Request permission[email protected]+44 07927 994619
Is the Porosi API publicly available?

No. There is no public self-service key or anonymous developer access. You must contact Porosi and receive explicit permission before credentials or production access are issued.

How do we request API permission?

Email [email protected] or use the request builder on this page. Include your organisation, supplier tenant, connected system, required data objects, read or write needs, estimated request volume and target launch date.

Does sending a request grant access?

No. It starts the technical review. Porosi must approve the integration scope before any onboarding details, credentials or production permission are provided.

Which data objects can be considered?

Typical discussions involve products, customer accounts, pricing context, orders, inventory or delivery information. Availability depends on the business purpose, tenant, security review and approved integration contract.

Can an integration read and write data?

Read and write actions are reviewed separately. Write access has greater operational impact and must be explicitly justified, validated and approved; it is never implied by read permission.

How is access restricted?

Approved access is designed around the integration identity, relevant tenant, agreed objects and actions, authentication requirements and service controls. Rate limits, quotas or additional restrictions may apply.

Are webhooks or event delivery automatically included?

No. If the workflow needs event delivery, callbacks, webhooks or polling, raise that requirement during technical review. It is assessed as part of the integration rather than assumed from API access.

  1. 01Contact
  2. 02Review
  3. 03Scope
  4. 04Validate
  5. 05Approve
API access is permissioned.

Tell us which system needs to join the Porosi order.

Bring the supplier tenant, data objects, read or write actions, expected volume and operational outcome. Porosi will review the route before any access is issued.

Request API permission Contact Porosi Book a workflow demo