Skip to main content
A workspace microservice is called the same way an instance microservice is: with the Microservice function, which behaves like an External API Request except that the traffic never leaves your environment.

​
One host list

The Host dropdown now merges both kinds of microservice:
  • Instance-level microservices, as before.
  • Workspace-level microservices, read live from the workspace.
They appear together, so a function stack doesn’t need to care which layer a service was deployed at.

​
Addressing a workspace microservice

A workspace microservice is addressed as its name and service port:
That bare form is what you pick from the Host dropdown. Xano rewrites it to the scoped Kubernetes Service name at call time, which is what makes the same function stack work unchanged in the workspace and in every tenant it’s deployed to — each resolves the name to its own copy of the service. The rest of the function is the same as any HTTP call:
  • Path — the path on the microservice, e.g. /api/generate
  • Method — GET, POST, PUT, PATCH, DELETE, HEAD, or OPTIONS
  • Params — query parameters or request body
  • Headers — any custom headers the service requires
  • Timeout — how long the function stack waits before treating the call as timed out
  • Follow location — whether to follow redirects
Import cURL builds the whole call from a cURL command, which is usually the fastest way to get started from a service’s own documentation.
Set the Timeout deliberately. The default suits a fast HTTP service; a microservice doing real work — a model generating tokens, a large PDF rendering — needs a higher value or it will time out mid-request.

​
Disabled microservices are excluded

A disabled microservice does not appear in the host list, and neither does one that has been undeployed. There is no running Service to proxy to, so offering it would only produce a call that fails. If a microservice you expect is missing from the dropdown, check its status on the detail page — it is most likely undeployed rather than misconfigured.

​
Traffic stays internal

As with instance microservices, calls to a workspace microservice are internal traffic. The request does not traverse the public internet, and data does not leave your environment to reach the service. This is the property that makes microservices usable for workloads you can’t send to a third party — a model running on GPU, PDF generation over HIPAA-sensitive data, media processing, a legacy system in a container.