Geiger Pods

Pods works inside a Geiger project. Open your organization in Dash and choose Pods on one of its projects. If Pods shows a lock, it isn't in your organization's plan. One Geiger account signs you in to Pods and every other app. Everything you create in Pods belongs to that project.

The sidebar lists Pods' areas: Overview, APIs, Usage, Security, Networking, Monitoring, Portals and Settings. Usage, Security, Networking, Monitoring and Settings expand to show their screens. To jump to any screen, type its name in Search Pods at the top.

Opening Pods without a project in the address opens the last project you used, or your first one. With no projects at all, Pods says so and links to Dash to create one.

The Pods playground opens a sample gateway without an account, so you can click through every area before you sign up.

Changes you make in the playground last until you reload the page. Anything that needs a real account or a live backend says "Not available in the playground".

Each area in the Pods sidebar covers one part of running an API gateway, and each has its own guide. The sections on this page sum them up and link to each one.

An API in Pods is REST (a tree of resources and methods), HTTP (simple routes) or WebSocket (a two-way connection). Choose APIs in the sidebar to create one, then click it to open the API editor, where you build its resources or routes, integrations to backends, authorizers, models and docs.

What you edit is the API's draft. Deploy snapshots the draft as a deployment and puts it on a stage, such as prod, with its own invoke URL. Stages also carry their own variables, caching, throttling and logging.

The APIs guide covers creating and managing APIs, and links to a guide for each part of the API editor. The Project overview guide covers the Overview screen, where traffic for every API is summed up.

Each deployment is a fixed snapshot, so you can compare two of them, point a stage back at an earlier one, or roll a stage back from its history. Each stage serves its deployment at its invoke URL, with its own stage variables, response cache, throttling and logging.

The Deployments and stages guide covers deploying, comparing, rolling back and every stage setting.

Pods has several layers for deciding who can call an API, and how much.

• Authorizers check a caller's JWT, or ask your own webhook, before a method or route runs. REST APIs can also have a resource policy. See Authorizers and resource policies.
• API keys identify each caller, and usage plans give their keys throttles and quotas on the stages they cover. See Usage plans and API keys.
• Security holds the secrets integrations send to backends, the web application firewall that filters REST stages, and the signing credentials for SigV4-signed calls. See Security.

• Monitoring shows requests, errors and latency on a dashboard you can narrow by API and stage, searchable request logs with traces, alarms that notify webhooks or Slack, and log exports to HTTPS, S3 or OpenTelemetry. See Monitoring.
• Portals publish developer portals: products with Markdown docs and endpoint pages, your branding, and optional sign-in. See Developer portals.

To document an API, import or export it as OpenAPI, generate a client SDK or serve it to AI agents, see Docs, SDKs and OpenAPI.

Your role in Pods comes from your role in the organization: Owner, Admin, Manager or Member. Owners and Admins can change everything, Managers build and release APIs, and Members read. The Team and access guide lists what each role can do.

Settings holds the project's throttle and log retention, access tokens for scripts, stacks and the audit log of every change. See Project settings.