Three Steps to Create Your Endpoint with Inquir Compute

Three Steps to Create Your Endpoint with Inquir Compute

If you need to ship a backend endpoint quickly, the ideal flow is simple: write the handler, test it, and publish it through the gateway. That is exactly how Inquir Compute is designed to work.

Inquir Compute gives you a browser-based editor, serverless runtimes for Node.js, Python, and Go, a built-in API Gateway, logs, traces, and hot containers in one workflow. Instead of stitching together separate tools for code execution, deployment, routing, and debugging, you can do everything from one place.

This guide walks through the fastest path to your first live endpoint.


Step 1. Create the function

Start in the Functions section and click + New Function. Give your function a name such as hello-world, choose a runtime, and open the editor.

Inquir Compute supports three runtimes out of the box:

  • Node.js 22
  • Python 3.12
  • Go 1.22

The built-in editor is based on Monaco, so you get a familiar coding experience directly in the browser, including multi-file editing and drag-and-drop file management.

For a simple HTTP endpoint in Node.js, you can start with a handler like this:

const payload = typeof event.body === 'string'
  ? JSON.parse(event.body || '{}')
  : (event || {});

exports.handler = async (event, context) => {
  return {
    statusCode: 200,
    body: JSON.stringify({
      message: 'Hello from Inquir Compute!',
      input: payload,
    }),
  };
};

A practical detail matters here:

  • when you click Run inside the editor, your JSON is passed directly as the event
  • when the function is called over HTTP, the request body arrives in event.body as a string

That is why parsing event.body conditionally is the safest default for endpoint-oriented handlers.


Step 2. Test and configure it before going live

Before exposing the function as an endpoint, run it locally inside the Inquir editor.

You can press Ctrl+Enter or click Run to invoke the function and inspect:

  • the returned result
  • logs
  • recent traces
  • execution history

This makes it easy to validate the contract of your endpoint before you publish it.

At this stage, you should also review the function configuration:

  • Handler — for example index.handler
  • Runtime — Node.js 22, Python 3.12, or Go 1.22
  • Timeout — default is 5000 ms
  • Memory — default is 256 MB
  • Network access — enable it only if your endpoint needs outbound HTTP or TCP
  • Environment variables — add secrets and config in the Config tab

Environment variables are configured per function and injected into the container at runtime. This is the right place for API keys, tokens, service URLs, and feature flags.

If your endpoint needs to call OpenAI, Stripe, Slack, GitHub, or any other external API, do not forget to:

  1. enable network access
  2. add the required credentials as environment variables

Step 3. Deploy it and expose the route through the API Gateway

Once the function works, click Deploy.

Deployment does two things for you:

  1. it publishes the function into the runtime environment
  2. it can warm up a hot container so repeated calls avoid the full cold-start path

After that, expose the function through the built-in API Gateway.

In the Gateway section, define the route for your endpoint:

  • choose the path
  • select the HTTP method: GET, POST, PUT, PATCH, DELETE, or ANY
  • choose the auth mode: Public, API Key, or Bearer Token
  • optionally set rate limits
  • optionally use path parameters like /users/:id
  • optionally use wildcards like /site/**

By default, workspace routes are served under:

/gw/<tenant-slug>/...

If you use named HTTP APIs, they are served under:

/gw/<label>/...

If your installation supports it, you can also bind a custom domain.

A typical public endpoint call looks like this:

curl -X POST https://your-host/gw/your-tenant/hello-world \
  -H "Content-Type: application/json" \
  -d '{"name":"Alice"}'

If the route is protected with API key authentication, call it like this:

curl -X POST https://your-host/gw/your-tenant/hello-world \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: your-key" \
  -d '{"name":"Alice"}'

At that point, your function is no longer just code in the editor. It is a live endpoint that can be used by frontends, webhooks, internal tools, cron-driven workflows, or external integrations.


What makes this flow fast

The reason this three-step flow works well is that Inquir Compute keeps the full backend path in one product:

  • write code in the browser
  • run and debug it immediately
  • deploy it without extra infrastructure work
  • expose it through the gateway
  • observe executions through logs and traces

You are not forced to wire together separate platforms for functions, routing, secrets, and debugging before you can ship a simple API.

That makes Inquir Compute especially useful when you want to launch:

  • a lightweight REST endpoint
  • a webhook receiver
  • an internal API for your frontend
  • an automation endpoint used by scheduled jobs
  • an AI-powered backend action

Final thoughts

Creating an endpoint in Inquir Compute is not a long DevOps process. In the shortest version, it is just this:

  1. Create a function
  2. Test and configure it
  3. Deploy it and publish the route

That is enough to go from idea to a live HTTPS endpoint with one platform handling runtime, gateway, and observability.

If you want the fastest first project, start with a single POST route that returns JSON, verify it in the editor, then publish it through the gateway. Once that works, you can extend the same function with auth, environment variables, path parameters, rate limits, or custom domains.


Sources