Skip to content

docs: Clarify how endpoint names map to client properties #767

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Benzzick wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs: Clarify how endpoint names map to client properties #767

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion versioned_docs/version-3.4.0/01-get-started/01-creating-endpoints.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -106,6 +106,10 @@ $ serverpod generate

`serverpod generate` will create bindings for the endpoint and register them in the server's `generated/protocol.dart` file. It will also generate the required client code so that you can call your new `generateRecipe` method from your app.

:::tip Endpoint names become client properties
In the next section you'll call `client.recipe.generateRecipe(...)` — not `client.recipeEndpoint.generateRecipe(...)` or `client.generateRecipe(...)`. That's not a typo: Serverpod derives the property name from your endpoint's class name by dropping the `Endpoint` suffix and lowercasing the first letter, so `RecipeEndpoint` becomes `client.recipe`. Every method you add inside the class shows up under that property, e.g. `client.recipe.generateRecipe(...)`. This mapping is generated automatically by `serverpod generate` above — there's nothing to configure by hand, but it's worth knowing the rule so the client code doesn't feel like it's coming out of nowhere.
:::
Comment on lines 107 to +111

@developerjamiu developerjamiu Aug 27, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tip covers a real gap: the 4.0 version of this page explains this mapping and the 3.4 page doesn't. Two things about the form though. It sits directly above an existing :::note, so the section runs prose, tip, note, heading, and callouts stacked like that compete rather than stand out. It also introduces the only em dash on this page.

The 4.0 page carries the same fact as one clause in a paragraph, which reads lighter here too:

Suggested change
`serverpod generate` will create bindings for the endpoint and register them in the server's `generated/protocol.dart` file. It will also generate the required client code so that you can call your new `generateRecipe` method from your app.
:::tip Endpoint names become client properties
In the next section you'll call `client.recipe.generateRecipe(...)` — not `client.recipeEndpoint.generateRecipe(...)` or `client.generateRecipe(...)`. That's not a typo: Serverpod derives the property name from your endpoint's class name by dropping the `Endpoint` suffix and lowercasing the first letter, so `RecipeEndpoint` becomes `client.recipe`. Every method you add inside the class shows up under that property, e.g. `client.recipe.generateRecipe(...)`. This mapping is generated automatically by `serverpod generate` above — there's nothing to configure by hand, but it's worth knowing the rule so the client code doesn't feel like it's coming out of nowhere.
:::
`serverpod generate` will create bindings for the endpoint and register them in the server's `generated/protocol.dart` file. It will also generate the required client code so that you can call your new `generateRecipe` method from your app. The class name's `Endpoint` suffix is dropped and the first letter lowercased, so `RecipeEndpoint` is called via `client.recipe`, and every method in the class appears under that property.


:::note
When writing server-side code, in most cases, you want it to be _stateless_. This means you avoid using global or static variables. Instead, think of each endpoint method as a function that does stuff in a sub-second timeframe and returns data or a status messages to your client. If you want to run more complex computations, you can return a `Stream` to yield progress updates as your task progresses.
:::
Expand Down Expand Up @@ -241,4 +245,4 @@ Try out the app by clicking the button to get a new recipe. The app will call th

## Next steps

@developerjamiu developerjamiu Aug 27, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This drops the trailing newline on a line the change doesn't otherwise touch. Restore it.

For now, you are just returning a `String` to the client. In the next section, you will create a custom data model to return structured data. Serverpod makes it easy by handling all the serialization and deserialization for you.
For now, you are just returning a `String` to the client. In the next section, you will create a custom data model to return structured data. Serverpod makes it easy by handling all the serialization and deserialization for you.
Loading