Forum Discussion
REST API has two endpoints for creating items. Which one should I use?
- 5 months ago
With this kind of question, you get the classic consultant answer: it depends. 😁
For a one-shot script or a small project → use the workload-specific endpoint (/warehouses, /lakehouses, etc.)
Why?It exposes the complete parameter surface for that item type (collation, SKU hints, etc.)
It tends to have better documented error responses for type-specific failures
It's the endpoint the workload team actually owns and tests against — so it's the most reliable
For generic tooling → use the generic Items endpoint (/items with itemType in the body)
Why? Because if you're building something that handles multiple item types uniformly — a deployment pipeline that creates N different items from a config file, or any automation where you want a single consistent call pattern; the generic endpoint is cleaner to work with. One function, one schema, swap the itemType and you're done.
With this kind of question, you get the classic consultant answer: it depends. 😁
For a one-shot script or a small project → use the workload-specific endpoint (/warehouses, /lakehouses, etc.)
Why?
It exposes the complete parameter surface for that item type (collation, SKU hints, etc.)
It tends to have better documented error responses for type-specific failures
It's the endpoint the workload team actually owns and tests against — so it's the most reliable
For generic tooling → use the generic Items endpoint (/items with itemType in the body)
Why? Because if you're building something that handles multiple item types uniformly — a deployment pipeline that creates N different items from a config file, or any automation where you want a single consistent call pattern; the generic endpoint is cleaner to work with. One function, one schema, swap the itemType and you're done.
Dear Cookistador , thank you for the answer 🙂
Makes sense... I hope both endpoints are supported equally.