# Sage X3 API Documentation: REST (Syracuse), SOAP Web Services and Where to Find Docs > Source: https://netray.co/erp-help/sage-x3-api-documentation-rest-soap > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Sage X3 exposes data and business logic in two main ways: REST-style SData services through Syracuse, which read and write business objects as JSON or XML, and SOAP web services that publish X3 subprograms and objects. Official documentation is in Sage's online help and developer resources for your version. ## Kind how-to ## System sage ## Erp Sage X3 ## Module Integration / Web services / REST ## Query sage x3 api documentation ## Alternate Queries - sage x3 rest api - sage x3 soap web services - sage x3 sdata endpoint ## Applies To Sage X3 V7, V11, V12 and later; endpoint paths and available features depend on version, patch and configuration ## Steps ### Getting started with the X3 APIs **Items:** - Decide the need: reading or writing business objects (REST) or calling a specific X3 function or subprogram (SOAP web service). - Create a dedicated integration user in Syracuse with the minimum role needed, and avoid a personal admin login. - For REST, discover the available representations for your folder in Syracuse, and request them with an authenticated call. - For SOAP, publish the object or subprogram as a web service in administration, assign it to a pool, and test with the generated WSDL. - Handle authentication per your setup (basic or token-based, TLS required) and restrict network access to the integration host. - Test pagination, filtering and error responses; log request ids so failures can be traced. - Version your integration against the X3 release and re-test after patches. ## Sections ### REST through Syracuse (SData) **Body:** Syracuse serves REST resources for X3 in a path pattern under the sdata prefix, naming the endpoint, the folder and the representation, for example sales orders, items or business partners. You can read collections with filters and paging, read single records, and, where the representation allows it, create or update with POST and PUT. Responses are JSON or XML. The Syracuse web client itself uses these services, so anything you can see on screen has a representation behind it. That is a good way to learn: inspect the calls the browser makes while you use a page. For a worked read example, see our page on reading sales orders through the REST API. ### SOAP web services **Body:** Classic X3 web services publish a subprogram or object to a SOAP endpoint with a WSDL. You publish it in the web services administration, assign a pool of processes to serve calls, and consume it from your integration tool. It suits legacy integrations and cases where you need to run specific X3 business logic. SOAP calls are tied to pools, so size and monitor them. A saturated pool is a common cause of timeouts that look like network problems. ### Where documentation lives **Body:** Start with Sage's official online help for your exact version, then Sage's developer resources and knowledge base. Your reseller or implementation partner can provide version-specific guides. Treat blog posts as hints only, because endpoint details change between versions. Whatever you build, keep the integration read-only until the data model is understood. Write calls should go through the same validations as the screens, so use representations and web services rather than database writes. ## Pitfalls - Using an admin user for the integration. - Writing straight to the database instead of through representations or web services. - Ignoring pool sizing, so SOAP calls time out under load. - Hardcoding endpoint details that change between versions. - No paging on collection reads, causing slow calls on large tables. ## Ai Angle An AI assistant needs governed access, not database credentials. A private AI layer such as ERPray can use a read-only integration user against REST representations or SQL views, apply X3 roles, show what it queried, and run on-prem. Write-back, where used, goes through representations with human approval. ## Faq ### Does Sage X3 have a REST API? **Answer:** Yes. Syracuse exposes REST-style SData services for X3 objects, returning JSON or XML. The set of representations depends on your version and configuration, so check them for your folder. ### What is the difference between REST and SOAP in X3? **Answer:** REST exposes business objects through Syracuse and suits modern integrations. SOAP web services publish X3 subprograms and objects with a WSDL, using pools of processes, and suit older integrations or specific business logic calls. ### Where is the official Sage X3 API documentation? **Answer:** In Sage's online help and developer resources for your version, plus the knowledge base and your reseller's documentation. Always match the documentation to your exact version and patch. ### Can I write data through the API? **Answer:** Yes, where the representation or web service allows it, and it runs through X3 validations. Test thoroughly in a non-production folder first, and use a least-privilege integration user. ## Search terms sage x3 api documentation, sage x3 rest api, sage x3 soap web services, sage x3 sdata, sage x3 syracuse api, sage x3 integration, sage x3 web service pool, sage x3 json api --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json