Endpoints

Each collection can expose these methods. Disabled methods are not callable, even with a valid token.

Method	HTTP	Path
list	GET	/api/p/:projectId/:table
get	GET	/api/p/:projectId/:table/:id
create	POST	/api/p/:projectId/:table
update	PUT	/api/p/:projectId/:table/:id
delete	DELETE	/api/p/:projectId/:table/:id
upload	POST	.../:id/files/:field/upload-sessions (then complete)
download	GET	.../:id/files/:field/:fileId
fileDelete	DELETE	.../:id/files/:field/:fileId

Bulk create is POST /api/p/:projectId/:table with a JSON array (max 100). Bulk update is PATCH /api/p/:projectId/:table with a filter. Bulk delete is DELETE on the collection URL with a filter. Create-many requires the create endpoint; update-many and delete-many require the matching write endpoint and at least one filter (see Query).

Disabled endpoint

When the endpoint row is missing or enabled is false, the handler returns 404 Endpoint not found or disabled. A valid token still gets that 404. The same string is used for bulk create (the create endpoint), bulk PATCH (the update endpoint), and collection DELETE (the delete endpoint).

GET /api/p/{projectId}/posts with list disabled:

curl -s "https://api.tefily.com/api/p/$PROJECT_ID/posts" \
  -H "Authorization: Bearer $TOKEN"

{ "success": false, "message": "Endpoint not found or disabled" }

File routes use their own 404 strings. See Files.

Bulk create max 100

POST with a JSON array uses create-many. A JSON object stays a single create. Create-many uses the create endpoint; there is no separate endpoint. Checks run in this order:

• Empty array: 400 Bulk create requires a non-empty array (no errors array).
• More than 100: 400 Bulk create allows at most 100 documents.
• An element that is not an object: 400 Bulk create item [i] must be a JSON object.
• Then each item’s create rules, then full validation. One validation error inserts nothing.

Success is 200 { "success": true, "data": { "insertedCount", "items" } }. SDK examples: Query.

Non-empty filter on PATCH and collection DELETE

PATCH /api/p/:projectId/:table?filter=<json> and DELETE on the collection URL reject an empty merged filter. Rule filters and the caller filter are combined as { "$and": [ ruleFilter, userFilter ] }. An empty merge is rejected:

• 400 Bulk update requires a non-empty filter
• 400 Bulk delete requires a non-empty filter

Both responses have message only. A rule-injected filter can satisfy a REST call that sends no filter. The JavaScript, Dart, and Python SDKs still throw before the request when there is no where: Bulk write operations require at least one where() condition. Keep the client where.

Single PUT vs bulk PATCH

Both need the update endpoint enabled.

	PUT /:table/:id	PATCH /:table?filter=
Validator	Full validation of the body	Partial validation of the patch
Omitted required field	400 Field "<name>" is required	Kept as stored
Explicit null on required	400	400
Unknown field	400 Unknown field "<key>"	Same
Bad type	400	400
Write	Merged onto the existing document, then replaced. Omitted optional fields stay	$set of the patch keys plus _updatedAt
Rules	Update rules against the existing document	Update rules as a list filter, then again as an update against the patch body

PUT still requires every required field in the body. Optional fields you leave out stay on the stored document. Bulk SDK examples: Query. Owner compares on that second PATCH pass: Access rules.

Console

Open the table → Endpoints and toggle methods. Copy the path from the API tester if you are calling REST directly.

Successful writes can notify your backend over HTTP. See Webhooks.

Rules attach to endpoints

Access rules are per endpoint. A list rule does not automatically apply to get. Add rules on every method your app uses.