Reference · built on requestConnectorPLC, SCADA & MES

Tulip

Table records, stations, users, and machine attributes from Tulip through the v3 and namespaced REST APIs.

Request accessPricing ↗

About

Tulip is a frontline operations platform where apps run at stations on the shop floor and store their data in Tulip Tables. Its public API is split into namespaces such as stations, users, machines, and tables, each versioned on its own under /api/{namespace}/{version}; the Tables endpoints still use the older /api/v3 prefix. Records are listed with filters on any column plus _createdAt and _updatedAt, sorted by field, and paged with limit and offset.

Through Fibric, an operator reads table records on a schedule, watches stations and machine attributes, and proposes a record update, a new record, or a reported machine attribute value. You approve. Each write is sent once and leaves a receipt: what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from Tulip and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Table records through GET /tables/{tableId}/records with filters, fields, sortBy, and sortDir
  • Record counts and field aggregations through the count and runAggregation endpoints
  • Tables, their queries, aggregations, and table link relationships
  • Stations, station groups, interfaces, and app assignments under /api/stations/v1
  • Users, user groups, and roles under /api/users/v1
  • Machine types and their machines, and machine activity archives generated on request

Proposed actions

  • Target capability: propose creating a record through POST /tables/{tableId}/records or updating one through PUT /tables/{tableId}/records/{recordId}
  • Target capability: propose incrementing or decrementing a numeric field on a record
  • Target capability: propose reporting machine attribute values through POST /attributes/report
  • Target capability: propose linking or unlinking records across a table link

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Close out a work order record from the floor

    Records whose status field is still open past their due date are listed each hour. The operator proposes the status update and the note to add, and waits for your approval.

    With Backlog Priority, Exception Routing

  • Put a lot on hold when a check fails

    A quality table record with a failed check arrives. The operator proposes a hold record in the lots table linked to the failing record and shows you both before writing.

    With Quality Hold, Lot Quarantine

  • Feed a machine's state from another system

    State values read elsewhere are reported to Tulip machine attributes through /attributes/report, once per change. Values that fail type validation are rejected as a batch, and the receipt shows which were sent.

    With Line Downtime, OEE Loss

Requirements

  • A Tulip instance on a Professional plan or above, where Service Accounts are available
  • A Service Account with the scopes each endpoint names; a missing scope returns an authorization error
  • A workspace context for global tokens, given as a /w/{workspaceId} path prefix or the X-Tulip-Workspace-ID header
  • Record filters on regular columns; linked record columns cannot be used as filter fields
Authentication
HTTP Basic Authentication with the credentials of a Tulip Service Account, formerly called an API Token, created under Settings with scopes such as tables:read, tables:write, machines:read, and attributes:report.

Limits

  • Record lists return at most 100 records per call, 10 by default; page with offset and includeTotalCount
  • Table rate limits per table: 10 record writes per second, 10 deletes, 50 single reads, and 10 multi-record reads
  • All Service Accounts on an instance share one rate-limit bucket per table and operation
  • A sortBy value that is not a table field returns a 422 error

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Tulip ↗

Questions and answers

How are Tulip API requests authenticated?
With HTTP Basic Authentication using a Service Account's credentials in the Authorization header. Each Service Account carries scopes, for example tables:read and tables:write, and each endpoint documents the scope it needs.
How does pagination work for table records?
With limit and offset query parameters. limit defaults to 10 and cannot exceed 100. Setting includeTotalCount returns the matching total in the X-Total-Count header at the cost of an extra database query. Sorting decides which records fall inside a page.
What rate limits apply to tables?
Per table within a workspace: 10 record writes per second, 10 deletes, 50 individual reads, and 10 multi-record reads. Limits are counted per instance, table, and operation, so extra Service Accounts do not raise them. Exceeding a limit returns HTTP 429.
Ask about Tulip

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Tulip through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy