How to Choose API Operations for Your First n8n Node

Choose the operations that let a user finish a real workflow. Include the lookups needed to supply IDs and other inputs, then check whether each action is understandable in the n8n editor. An endpoint list is a useful starting inventory. It is a poor release plan on its own.

I used the TidyCal node built with NativeShip to examine that gap. TidyCal's API covers booking types, bookings, contacts, and teams. The generated node exposes many of those operations, but its menu and fields show why an imported operation still needs an editorial review. This article is a review of the documented API and package source; I have not run an authenticated booking through the node.

Start with the job, then map the API calls

Imagine an n8n user who wants to book an available appointment. The TidyCal API documentation gives us a practical dependency chain:

What the workflow needs	API operation	What the user gets
A booking type ID	GET /booking-types	Available booking types and their IDs. The list accepts a page parameter.
A time the person can book	GET /booking-types/{bookingType}/timeslots	Available slots within a required UTC start and end range.
The booking itself	POST /booking-types/{bookingType}/bookings	A booking created with the person's name, email, timezone, and a selected start time.
A later lookup, if the workflow needs one	GET /bookings/{booking}	The booking identified by its ID.

The first three calls make a sensible candidate set. A node with only “Create Booking” still leaves the user hunting for a booking type ID and an available slot. The fourth call earns its place when a follow-up workflow needs to retrieve the booking.

The API also offers cancellation. I would add it for a defined cancellation workflow, alongside a way to find the right booking ID. I would not add team administration to this first booking flow merely because the endpoints appear in the specification. That is a separate job with different permissions and consequences.

In the workflow, the chain looks like this:

List Booking Types   → returns bookingType.id
      ↓
List Available Timeslots (bookingType.id, UTC start, UTC end) → returns a slot start time
      ↓
Create Booking (bookingType.id, slot start time, name, email, timezone)

Each step supplies an input the next one needs. That is the test for whether a lookup action belongs in the first release.

Use three checks to decide what stays

For each candidate action, write down:

1. The workflow that needs it. “Create a booking after a form submission” is specific enough to test. “Expose all booking endpoints” is not.
2. Where its required inputs come from. If an action needs an ID, a date range, or a token, the user needs a reliable way to supply it. A companion list action, a resource locator, or clear field guidance may solve that problem.
3. What happens after it runs. Check the response a following node will receive and what errors the user must handle. TidyCal documents different response shapes for single bookings and package bookings. It also documents a conflict response when the requested slot cannot be booked.

This produces a smaller, more useful release candidate than endpoint counting. It also gives you a test plan: if you cannot supply the inputs or inspect the result, the action is not ready to be described as working.

The source specification can help. Clear operation names, required fields, authentication, and examples make generated forms easier to review. The OpenAPI specification guide explains what to fix there. You still need to inspect the node that people will use.

Name the action for the thing it does

In the published TidyCal node source, “Create Booking” appears under the Booking Type resource. Its picker action says “Create booking booking types.” The API route starts with /booking-types/{bookingType}, which explains how that grouping arose. A person looking to create a booking would more naturally look under Booking.

Here is the edit I would evaluate:

In the reviewed node	Proposed editor choice	Keep in the form
Booking Type → Create Booking	Booking → Create	Booking Type ID, booker details, and booking time.
Booking Type → List Available Timeslots	Booking Type → List Available Timeslots	Booking Type ID and UTC date range.
Booking → Cancel	Booking → Cancel	The booking ID and an explicit description of the effect.

These are recommendations for a future edit, not changes already shipped. n8n's node UX guidelines distinguish the short operation name shown inside the node from the action label shown in the node picker. They also advise using the service's terminology and naming the object the action affects. “Create” can work under Booking; the picker label should still make clear that it creates a booking.

Inspect the form, not only the menu

The reviewed node makes Booking Type ID, name, email, and timezone visible required fields for Create Booking. It puts starts_at in “Additional Fields.” TidyCal requires that start time for a single booking; a package booking instead uses a bookings array. The generated form does not make that choice obvious.

I would separate the two cases in the form, or use a booking mode that shows the relevant field and marks it required. Then I would check the values a user must enter:

• Can they select or retrieve the booking type ID instead of guessing it?
• Does the timeslot action explain that its start and end range is UTC?
• Does the single-booking form require a start time and show a usable date example?
• If package bookings remain in scope, does the form explain the array format and the different output shape?

That review catches problems an OpenAPI import cannot settle by itself. The form has to translate API requirements into choices a workflow builder can understand.

Keep the package to one service and plan for AI agents

n8n's verification rules allow one service per package, so scoping is about which of that service's jobs to cover, not about bundling neighbouring tools. Choose actions for the jobs people bring to n8n, and leave admin-only endpoints for a later release.

The operations you keep also become tools when someone connects the node to an n8n AI Agent. Short, specific action names and field descriptions help a model pick the right call and fill the inputs. "Create booking" with a described start-time field is easier for an agent to use than a generic "POST booking-types bookings" label. The AI agent tool guide covers what to check.

Test the request path before calling the node usable

The current TidyCal package has a more basic problem. Its source declares credentials: [], although TidyCal's API requires authenticated access. Generated destination fields also default to https://api.example.com; the source's server URL construction needs review. I have not captured a successful authenticated TidyCal execution from this package.

Before release, I would correct authentication (see how to add a credential test) and the request destination, then run a small test set in n8n:

Test	What to inspect
List booking types	The request reaches TidyCal with valid credentials and returns the expected IDs.
List timeslots	The booking type and UTC range are sent correctly; the response contains the slots the next action needs.
Create one test booking	The node sends the selected slot and required booker fields; the response can be used by the next node.
Try a slot that is no longer available	The node gives the user a useful error instead of treating the booking as successful.

Use an account and booking type where a test booking is appropriate, and inspect the actual request and response. A package that builds successfully has passed a build step. It has not passed these API tests. The generated-node testing guide walks through the full check.

If you are importing your own API into NativeShip, the OpenAPI-to-n8n guide shows the resource and operation review in the editor. Bring one workflow you want customers to complete. When you start a NativeShip project, use that workflow to decide which generated actions to keep, rename, or test next.