If you generate a project using the Umbraco Extension Template | CMS | Umbraco Documentation
Then much of this boiler plate is done for you..
make use of npm run generate-client and then you get an import to use..
(it generates this from the api controllers you add to the project.. with the examples there are already a few there)
import { InviteToConfigurePlotService } from "../api/index.js";
...
const {data, error } = await InviteToConfigurePlotService.whoAmI({
body: bodyData
});
And the auth headers are all ready all in place for the backoffice comms..
in the entrypoint.ts
import type {
UmbEntryPointOnInit,
UmbEntryPointOnUnload,
} from "@umbraco-cms/backoffice/extension-api";
import { UMB_AUTH_CONTEXT } from "@umbraco-cms/backoffice/auth";
import { client } from "../api/client.gen.js";
// load up the manifests here
export const onInit: UmbEntryPointOnInit = (_host, _extensionRegistry) => {
console.log("Hello from my extension 🎉");
// Will use only to add in Open API config with generated TS OpenAPI HTTPS Client
// Do the OAuth token handshake stuff
_host.consumeContext(UMB_AUTH_CONTEXT, async (authContext) => {
// Get the token info from Umbraco
const config = authContext?.getOpenApiConfiguration();
client.setConfig({
auth: config?.token ?? undefined,
baseUrl: config?.base ?? "",
credentials: config?.credentials ?? "same-origin",
});
});
};
export const onUnload: UmbEntryPointOnUnload = (_host, _extensionRegistry) => {
console.log("Goodbye from my extension 👋");
};
ps.. My project name was InviteToConfigurePlot so yours would be different. ![]()
.. though they don’t use the ManagementApiControllerBase, they are backoffice protected, I think this is only so that you don’t have to have /management/ in the backoffice route)
[ApiController]
[BackOfficeRoute("invitetoconfigureplot/api/v{version:apiVersion}")]
[Authorize(Policy = AuthorizationPolicies.SectionAccessContent)]
[MapToApi(Constants.ApiName)]
public class InviteToConfigurePlotApiControllerBase : ControllerBase
{
}
but nothing to stop you changing this to suit your requirements.
One other gotcha.. the default dependencies from the extension template are set as * I’d recommend setting these to concrete versions… otherwise you’ll find any project consuming this project will update to the latest umbraco version, which you may not want..
<ItemGroup>
<PackageReference Include="Umbraco.Cms.Web.Website" Version="*" />
<PackageReference Include="Umbraco.Cms.Web.Common" Version="*" />
<PackageReference Include="Umbraco.Cms.Api.Common" Version="*" />
<PackageReference Include="Umbraco.Cms.Api.Management" Version="*" />
</ItemGroup>
Umbraco self upgrading from 17.1.0 to 17.2.0 on Azure Web App - Umbraco community forum
If it’s a nuget package you are creating, the opinionated starter kit is also great!
GitHub - LottePitcher/opinionated-package-starter: Get a head start when creating Umbraco Packages · GitHub (it wraps the extension project with lots of package development sugar.. test site etc)