ecyrbe / zodios Goto Github PK

We can improve zodios with named calls in addition to endpoints calls.
Examples:

const client = new Zodios (BASE_URL, [
  {
    method : 'get',
    path: '/users',
    alias: 'getUsers',
    parameters: [...]
  }
  ]);

Then we could call it like that:

  client.get('/users');

Or with it's alias :

  client.getUsers();

Zodios should allow to declare multiple security schemes for openapi

We could add something like this :

const document = toMultiSchemeOpenApi({
  info: {
    title: 'Project A API',
    version: '0.0.0',
    description: 'A simple example API',
  },
  servers: [
    {
      url: '/',
    },
  ],
  securitySchemeAPIs: [
    {
      name: 'basic',
      securityScheme: basicAuthScheme(),
      api: basicAuthAPI,
    },
    {
      name: 'bearer',
      securityScheme: bearerAuthScheme(),
      api: bearerAuthAPI,
    },
    {
        api: notSecuredAPI, // for health check, etc
    }
  ] 
});

Currently we can validate both the request payload sent and the response content using validate or none

Continuing my reasoning (and use-cases for openapi-zod-client) that not all APIs are in our own control, and therefore that we can only control what we send in the request payload,

would you consider having a validate mode (as a string enum ?) with the current boolean ?

something like:
validate: "request" | "response" | boolean

tbh I don't know if a response mode would really be useful but I added it in the example above so that every options are available

If I have the following API and endpoint:

const userApi = makeApi([
  {
    method: 'get',
    path: '/users/:id',
    alias: 'getUser',
    description: 'Get a user',
    parameters: [
      {
        name: 'id',
        type: 'Path',
        schema: z.number(),
      },
    ],
    response: z.object({
      id: z.number(),
      name: z.string().nullable(),
    }),
    errors,
  },
]);

const userRouter = ctx.router(userApi);

userRouter.get('/users/:id', async (req, res) => {
  console.log(typeof req.params.id);

  return res.json({
    id: req.params.id,
    name: "example",
  });
});

The output of the console.log() is string, even though the type is inferred as number.

Express does not have a context per say.
Users usually use req object and inject their context in there.
Since zodios is aimed at typesafety and discoverability, we should add one.

const context = z.object({
   user: z.object({
     name: z.string(),
     email: z.string().email(),
   })
});

const app = zodiosApp(userApi, { context });

app.get('/users', (req, res) => {
  // user is typed and req has autocompletion
  const user = req.user;
  if (isAdmin(user)) {
    res.status(403).json (...);
  }
  ...
});

It's me again!

I've got a small issue which I'm hoping isn't a pain to resolve.

Essentially when performing a transform on a schema for a parameter, it seemingly infers the incorrect type. I've added an example below:

const refreshClient = new Zodios(url, [
  {
    method: "post",
    path: "/oauth_token.do",
    alias: "getRefreshTokenWithCode",
    parameters: [
      {
        name: "body",
        type: "Body",
        schema: z
          .object({
            code: z.string(),
            client_id: z.string(),
            client_secret: z.string(),
            redirect_uri: z.string().url(),
          })
          .transform(
            (value) =>
          ),
      },
    ],
    response: z.object({
      access_token: z.string(),
      refresh_token: z.string(),
    }),
  },
] as const);

const refreshResponse = await refreshClient.getRefreshTokenWithCode(
      {
      code,
      client_id: process.env.SERVICENOW__CLIENT_ID,
      client_secret: process.env.SERVICENOW__CLIENT_SECRET,
      redirect_uri: process.env.SERVICENOW__REDIRECT_URI,
    }
  );

What I'd like to be able to do is to effectively simplify the inputs via a transform?

Senario

For my experience, it quite often to use a POST request for searching resource or pagination.
For example:

POST /users/search HTTP/1.1
Accept: application/json
Content-Type: application/json

{
  "gender": "female",
  "limit": 20
}

Proposal

Maybe it could be

export const Request = z.object({
  gender: z.enum(["male", "female"]),
  limit: z.number().min(0).max(200),
});

export const Response = z.object({});

export type User = z.infer<typeof Request>;

export const userApi = makeApi([
  {
    method: "post",
    mutation: false, // <-- explicitly make it useQuery-able
    path: "users/search",
    parameters: [
      {
        name: "body",
        type: "Body",
        schema: Request,
      },
    ],
    response: Response,
  },
]);

I'm really liking this library so far. For context I'm creating a web app which acts essentially as an aggregator for other API's and Zodios is doing a lot of the heavy lifting for me, so firstly thank you! 😍

I've noticed that the error's that are reported from a failed response parsing are just throwing the ZodError, without any further context.

ZodError: [
  {
    "code": "invalid_type",
    "expected": "array",
    "received": "undefined",
    "path": [
      "value"
    ],
    "message": "Required"
  }
]

My ideal solution would give additional context, such as the URL called with an option to enable the original response content to be shown. It may be possible/more suitable for this functionality to live inside a plugin, which I'll start to investigate if it's possible to do so now. Thought I would just get the ball rolling, in the case where this is actually a lot simpler than it seems.

The typing of select was introduced due to #158

For convenience, a codesandbox to demo the bug here.

The bug is described by comments of following code block

const { data } = apiHook.useUser(undefined, {
  //    ^^^^
  //    data is NOT reflecting to return type of select
  select:
    // ^^ zodios is forcing me follow the type Response
    () => ({
      first_name: "first"
    })
});

function useUser() {
  const { data } = useQuery(["key"], () => ({ name: "name" }), {
    // ^^^^
    // data is reflected to return type of select
    // typed as {
    //   first_name: string;
    // } | undefined
    select: () => ({ first_name: "first" })
  });
}

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update dependency rimraf to v5.0.10
• chore(deps): update dependency @types/node to v20.14.15
• chore(deps): update dependency ts-jest to v29.2.4
• chore(deps): update dependency typescript to v5.5.4
• chore(deps): update dependency rimraf to v6
• Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• chore(deps): update dependency express to v4.19.2 [security]
• chore(deps): update dependency axios to v1.6.0 [security]
• chore(deps): update dependency @types/express to v4.17.21
• chore(deps): update dependency @types/jest to v29.5.12
• chore(deps): update dependency @types/multer to v1.4.11
• chore(deps): update dependency ts-node to v10.9.2
• chore(deps): update dependency zod to v3.23.8
• chore(deps): update github/codeql-action action to v3
• chore(deps): update orhun/git-cliff-action action to v3

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

The relevant link contains "]" at the end.

Discussed in #197

Problem

A sample codesandbox for demonstrating the bug

And note that, following the doc, I installed @tanstack/react instead of react-query.

Possible Solution

A simple solution is to install react-query@3.

But maybe this library should use @tanstack/react instead.

Sorry I can't locate the right spot for the breaking code. And also, I can't figure out how this library were importing react-query. It's even not marked as a dependency in package.json. Hope the provided information is enough.

When the error sent by a API request doesn't conform to the defined schema, Zodios replies just with Zodios: Invalid response, there should be a description of what's missing and what it's receiving

Because I'm populating the queries object before passing to the Zodios endpoint and would like to reuse this type in the object to avoid repetition.

I feel like the API for declaring parameters could be simplified, it seems a bit verbose:

apiBuilder({
  path: '/marketplaces/:id/transactions',
  method: 'get',
  alias: 'getMarketplaceTransactions',
  // if it were a POST
  body: {
    .....
  },
  queries: {
      limit: z.number().optional()
      offset: z.number().optional()
      'date_range[gte]': z.string().optional()
      'date_range[lte]': z.string().optional()
  },
  headers: {
    Authorization: z.string()
  },
  // if the user really wants description for openAPI:
  description: {
     queries: {
        limit: 'A parameter to limit the number of rows returned'
     }
  },
  response: transactionsSchema,
})

Besides being less verbose, the parameter types have the same name as the objects in the API client (queries, headers) so it's intuitive

Steps to reproduce:

1. clone https://github.com/QzCurious/zodios-hook-bug
2. yarn
3. yarn dev
4. visit http://localhost:3000
5. The line apiHook.useUser() produce the error
   

It's just a simple nextjs project installed with necessary dependencies of @zodios/react. It might be easier to inspect this demo by checking what each commit does instead of reviewing whole project.

Side note: The same setup working fine with CRA on codesandbox here.

We currently have an file with a bunch of route definitions. The readability really starts to get worse as the file grow, having an makeEndpoint method would be specially useful when we want one definition per file, e.g:

// getUser.ts

export default makeEndpoint({
  method: "get",
  path: "/users/:id",
  alias: "getUser",
  description: "Get a user",
  response: z.object({
    id: z.number(),
    name: z.string(),
  }),
})

// createUser.ts

export default makeEndpoint({
  method: "post",
  path: "/users",
  alias: "createUser",
  description: "Create a user",
  parameters: [{
    name: 'body',
    type: 'Body',
    schema: z.object({
      name: z.string(),
    })
  }],
  response: z.object({
    id: z.number(),
    name: z.string(),
  }),
})

// api.ts
import getUser from './getUser';
import createUser from './createUser';

// It could also be compatible `makeApi` as well.
const api = new Zodios([getUser, createUser])

Thanks for a great library! I really like it.
I've been working with API which requires passing an array of IDs.
for example:

  {
    method: 'get',
    path: '/users',
    alias: 'getUsers',
    parameters: [
      {
        type: 'Query',
        name: 'id',
        schema: z.array(z.string()),
      },
    ],
    response: z.array(z.object(...)),
  })

currently, zodios generates following URL:

http://localhost/users?id=1,2,3

however, the standard URL API does not recognize it as an array

> new URL('http://localhost/users?id=1,2,3').searchParams.getAll('id')
['1,2,3']

I think the standard representation of an array of searchparams would be:

http://localhost/users?id=1&id=2&id=3

> new URL('http://localhost/users?id=1&id=2&id=3').searchParams.getAll('id')
['1', '2', '3']

can I change the encoding of an array?

I can see Zodios workflow being very useful for service to service communication through events, streams, message queues, raw TCP, etc

This is something I have wanted to be able to do a few times now and doesn't seem possible. Could be solved via the Zod default function if all the params/query fields were parsed with the schema (I don't see that happening anywhere but maybe I missed it), that's what I have tried so far.

The data parameter of axios is omitted from get method by ZodiosRequestOptionsByPath.

Note: Sending body/payload in a GET request may cause some existing implementations to reject the request — while not prohibited by the specification, the semantics are undefined. It is better to just avoid sending payloads in GET requests.
MDN

Could zodios be less opinionated about it?

Something like:

apiBuilder({
    method: 'get',
    path: '/orders/:order/status',
    alias: 'getStatusOrder',
    parameters: [
      {
        type: 'Path',
        name: 'order',
        schema: z.string(),
      },
    ],
    response: {
      schema: OrdersGetStatusOutputSchema,
    },
  })

Since v10, we can refine the schema of path parameters.
But the type have not been updated.
Indeed they are still of type string | number. we should narrow to zod ineffered type if it was provided.

There is a new player in the field of TS runtime validation libraries. typescript-json adds a plugin transform to tsconfig.json and can work with existing TS types.

Pros

• No need to add a extra DSL for runtime, just use the TS interfaces/types
• Supports anything fancy in TS level
• Much faster than zod
• Has a "comment tag" API for richer validation
• Might simplify zodios internals

Cons

• Doesn't have transforms
• Zod has better error output

I understand the library is deeply committed to zod but anyway I thought it would be interesting to share this, might be gamechanging.

Suppose I have a url like https://endpoint.com/:id/transactions and I will always pass the same id. Is it possible to inject this parameter on the client so I don't need to add it to the call everytime and make the typechecker happy?

I have a parameter defined as

{
      name: 'querystring',
      type: 'Query',
      schema: z.object({
        limit: z.number().optional(),
        offset: z.number().optional(),
        'date_range[gte]': z.string().optional(),
        'date_range[lte]': z.string().optional(),
      }),
    }

If I don't pass { queries: {querystring: {}} to the API call the typechecker will complain.

According to react-query. select function in QueryObserverOptions will get returned data from query function.

This is where zodios failed to infer the type of return data.

Hi, query string as an array again!
I'm useing Zodios with a GraphQL DataLoader.

example:

const userResponse = z.array(
  z.object({
    id: z.number(),
    name: z.string(),
  })
}),

type UserResponse = z.infer<typeof userResponse>

const apiClient = new Zodios(
  "https://example.com",
  [
    {
      method: "get",
      path: "/users",
      alias: "getUsers",
      parameters: [
        {
          type: 'Query',
          name: 'keys',
          schema: z.array(z.string()).min(1),
        },
      ],
      response: userResponse,
    },
  ],
);

const loader = new DataLoader<string, UserResponse>(
  async function batchFunction(keys) { // keys: readonly string[]
    const response = await apiClient.getUsers({ queries: { keys: keys as string[]} })
    ...
  }
)

It's works very well but unfortunately it needs cast because a DataLoader passes a readonly array.
I don't think Zodios will change the passed config (In fact, Zodios internally casts them as read-only.), so could you concider adding readonly to the config parameter deeply?
(Probably the same for the body parameter of the post method, etc.)

If we define the parameters array outside of the parameter definition like this:

apiBuilder({
  path: '/marketplaces/:id/transactions',
  method: 'get',
  alias: 'getTransactions',
  parameters: queryStringStandardParameters,
  response: transactionsSchema,
})

The typechecker complains with:

To keep things simple, as of today most browser support HTTP 2, so SSE doesn't have those disadvantages of the past and can replace Websockets anywhere you aren't building a FPS-shooter on the browser :)

So it's a simpler architecture and built upon HTTP already. Some GraphQL projects are already adopting SSE as the standard for subscriptions, like graphql-yoga for example.

What do you think?

Hello and thanks for this great library!

I have a question that I haven't been able to resolve, maybe there is a solution but I missed it in the docs and couldn't find an answer through Google/Stackoverflow either.

Let's say I have a GET endpoint that requires multiple query parameters in the request. How can I implement this with zodios?

{
  method: "get",
  path: "/users/:id", // id here is a single optional parameter
  alias: "getUser",
  description: "Get a user",
  response: z.object({
    id: z.number(),
    name: z.string(),
  })
}

But my endpoint is using multiple parameters like so: /users?page=1&pageSize=10&name=test

How can I add these parameters and type them as I want? I fiddled around and couldn't make it work with multiple parameters like /users?page=:page&pageSize=:pageSize&name=:name. I also want to type these input parameters.

This is a feature request to allow the BaseUrl to be optional when initialising Zodios.

The reason for this is that I want to have use a relative path, instead of an absolute path to fetch data from the web server the app is running under (As I'll be running zodios in the browser).

I'm not sure what I'm doing wrong, but I'm only getting types coming through when I use the apiBuilder helper, but if I use makeApi the types look messed up, see the screenshot below. Is this a bug or am I not using makeApi as intended?

Discussed in #176

{
    method: 'get',
    path: '/users/:id',
    alias: 'getUser',
    description: 'Get a user',
    response: z.object({
      id: z.number(),
      name: z.string().nullable(),
    }),
},

{
    method: 'get',
    path: '/users/:id',
    alias: 'getUser',
    description: 'Get a user',
    parameters: [
      {
        name: 'id',
        description: 'The user id',
        type: 'Path',
        schema: z.string().uuid(),
      },
    ],
    response: z.object({
      id: z.number(),
      name: z.string().nullable(),
    }),
},
```</div>

Axios only having XHR implementation by default is a real pain nowadays. Some options are only available in fetch (keepalive).

Zodios should implement a fetch adapter to keep using axios goodies and add missing options to Zodios to allow fetch to use them in the adapter.
Here are old implementations for example purpose :

• https://github.com/vespaiach/axios-fetch-adapter
• https://github.com/skayo/axios-ky-adapter

I've define a body parameter for my post request. But I can ignore data without ts showing error.

codesandbox

import { makeApi, Zodios } from "@zodios/core";
import { z } from "zod";

export const Request = z.object({
  page: z.number().int().min(1),
  perpage: z.number().int().max(20)
});

const Response = z.object({});

const userApi = makeApi([
  {
    method: "post",
    path: "user/list",
    alias: "userList",
    immutable: true,
    parameters: [
      {
        name: "body",
        type: "Body",
        schema: Request
      }
    ],
    response: Response
  }
]);

const apiClient = new Zodios(userApi);
apiClient.userList(); // <-- data should be required
apiClient.post("user/list"); // <-- data should be required

So it seems that zodios has issues with typescript v4.5.4.

Identify which version of typescript zodios is compatible with and make this a peer dependency.

Hey @ecyrbe, this is fantastic!

In my org, we recently moved off axios and started using a small custom fetch-wrapper. We really want to use this but we don't want to go back to axios. It would be awesome if we could provide a custom fetcher to this lib. Is this something you may consider?

I understand if this is out-of-scope for this lib.

Thanks!!

idk if that is even possible but I expected this error at compile-time

const apiEndpoints = makeApi([
  {
    method: 'delete',
    path: '/cart/clean',
    requestFormat: 'json',
    parameters: [
      {
        name: 'storeId',
        type: 'Query',
        schema: z.number(),
      },
    ],
    response: z.string(),
  },
]);
const client = new Zodios(apiEndpoints);

// no error, should have error
client.delete('/cart/clean');

// no error, should have error
client.delete('/cart/clean', undefined);

// expects error, is fine
client.delete('/cart/clean', undefined, {});

// expects error, is fine
client.delete('/cart/clean', undefined, { queries: {} });

I think there is the same behaviour with header params

One of the good ideas of zodios is to use plain objects to declare APIs.
This make api definition easier to read, faster to write. But it comes at a cost :

• A lot of typescript utility types had to be made to parse the definition and transform it.
• When you have made a mistake typescript create cryptic messages for your whole definition instead of highlighting where the error is.
• Autocompletion is somewhat broken sometimes (all optional properties don't seem to have autocompletion once one endpoint has been written)

Needs investigation to improve this and maybe simplify the whole thing if possible

We could improve zodios with CRUD generation feature to remove unnecessary duplicated declarations :

client = new Zodios(BASE_URL, 
  CRUD('users', { schema: zodUserSchema }));

I'm seeing an issue where the plugins are applied in one order for 2 requests and then in a different order after that, leading to problems with a plugin that modifies the API response before it reaches the zod validation plugin. So the first 2 requests fail and then the 3rd succeeds because the response transform plugin is now processed before the zod validation plugin.

It seems to be because of this in-place reverse happening here https://github.com/ecyrbe/zodios/blob/main/src/plugins/zodios-plugins.ts#L111

If I locally change that to [...this.plugins].reverse() the problem goes away. Using v9.3.1 of @zodios/core.

P.S. Love the library so far, building an Observable variant of the zodios hooks package to use with XState ontop of @tanstack/query-core

Returned type of createQuery of @zodios/solid in combination with transform is wrongly inferred.

const result = createQuery('get','/user', undefined, { select: ()=> ({ test: 'hello' }) });
result.data;
//      ^? type result !== { test: string }

Apply the same fix as @zodios/react : ecyrbe/zodios-react@c8c9ffd

👋 Hello, it's me again!

What do you think on adding a helper function which can infer the response shape of an alias?

For example I have the following client configured:

export const client = new Zodios("https://example.com", [
  {
    method: 'get',
    path: '/api/get_thing',
    alias: 'getThings',
    response: z.object({
      result: z.string()
    })
  },
] as const);

It would be really cool if we could do something like the following:

import { InferResponse } from "@Zodios/core";

type getThingsResponse = InferResponse<"getThings">
// { result: string; }

This is very similar to the following: https://trpc.io/docs/infer-types

The reason I ask for this is because I'm using SvelteKit and right now the typing between the backend and frontend isn't that strong, so I have to extract my types/schemas into a separate file and import into both places which works but isn't as smooth as I'd like 😄

Hi there! First, I'd like to thank you for this library. I have been using it for some time and I love it!

I have been working with API, which requires passing an Organization ID within the endpoint path, for example:

/v1/organizations/**organization_id**/shipments

Is it possible to set that ID globally for API client instance? I would prefer to avoid passing it in every operation as variable.

Thanks!

Hey, I have a use-case where I need to inject a custom base URL depending on the request config, to do so i'm currently using a plugin creator (the baseUrl is an env var fetched at runtime and dynamic by country to be specific..)

it looks kind of like this:

const endpoints = makeApi([
  {
    method: 'get',
    path: '/v1/stores/:store_id',
    requestFormat: 'json',
    response: variables.d,
  },
  {
    method: 'get',
    path: '/v2/customer/:customer_id',
    requestFormat: 'json',
    response: variables.d,
  },
]);
// no baseUrl provided since it's only known at runtime
export const api = new Zodios(endpoints);

// ...
const createApiPlugin = (apiId: ApiId) => {
  return {
    name: 'apiPlugin',
    request: async (_endpoint, config) => {
      const state = xxx;
      const baseUrl = xxx[apiId];
      return { ...config, url: `${baseUrl}${config.url}` };
    }
  }
}

but then I get an error because the endpoint is not found in the response

would it be ok to allow overriding a baseUrl in the return of the plugin.request rather than overriding url completely ? i think this would solve my use-case and would not break anything

Hi, I've created a Zodios client plugin which uses the following utilities:

import { findEndpoint } from '@zodios/core/lib/plugins/zodios-plugins.utils'
import { replacePathParams } from '@zodios/core/lib/utils'

It worked fine until v10.2.0, however since v10.3.0 these utilities are no longer visible.
These may not have been intended to be public APIs, but I think they are very useful.

Is it possible to use these utilities in a custom plugins? Or is there an alternative?

I have a parameter with the Header type defined as:

{
  type: 'Header',
  name: 'token',
  schema: z.object({
    Authorization: z.string().transform(s => {
      return `Basic ${Buffer.from(s + ':').toString('base64')}`
    }),
  }),
}

But when I try to use it like this:

zoop.getMarketplaceTransactions({
  params: { id: marketplace_id },
  headers: {
    token: {
      Authorization: key,
    },
  },
})

The typechecker complains about the object shape:

Hi! 👋

Firstly, amazing project - one of the best typed libraries I've seen.

I have a small improvement suggestion - would be great, if the Zod validation utility searching for schema to apply to the response took into account also the alias name, not just the method with the path. This would allow forming multiple endpoint descriptions for the same endpoint, for which developer expects to receive different results (e.g. depending on type of entity returned).

Sample use case
The GET /vehicle/:id/state endpoint returns a vehicle that can be of different types (either a car, or a ship, or a bike) and so the responses would be different too (1st would return fields like consumedGas, 2nd: isSailFolded, etc.). While it's possible to create a schema with discriminated union for those, it might end up to be a big union. Also, in some cases, knowing the context of the query, it might make sense for it to only return one of the vehicle types (e.g. a dashboard panel displaying tire pressure wouldn't be satisfied with ship vehicle being returned). For such situations, a developer might create endpoint descriptions for the same endpoint, but with different response validation schemas and of course different aliases: getCarState, getShipState, etc.

I used patch-package to fast-forward this functionality locally, and it works perfectly - here's the code for the core and react packages:

diff --git a/node_modules/@zodios/core/lib/plugins/zod-validation.plugin.js b/node_modules/@zodios/core/lib/plugins/zod-validation.plugin.js
index 2578894..c10620e 100644
--- a/node_modules/@zodios/core/lib/plugins/zod-validation.plugin.js
+++ b/node_modules/@zodios/core/lib/plugins/zod-validation.plugin.js
@@ -48,7 +48,7 @@ const plugin = {
         return conf;
     }),
     response: (api, config, response) => __awaiter(void 0, void 0, void 0, function* () {
-        const endpoint = (0, zodios_plugins_utils_1.findEndpoint)(api, config.method, config.url);
+        const endpoint = (0, zodios_plugins_utils_1.findEndpoint)(api, config.method, config.url, config.fromAlias);
         /* istanbul ignore next */
         if (!endpoint) {
             throw new Error(`No endpoint found for ${config.method} ${config.url}`);
diff --git a/node_modules/@zodios/core/lib/plugins/zodios-plugins.utils.js b/node_modules/@zodios/core/lib/plugins/zodios-plugins.utils.js
index ba5828e..478af9c 100644
--- a/node_modules/@zodios/core/lib/plugins/zodios-plugins.utils.js
+++ b/node_modules/@zodios/core/lib/plugins/zodios-plugins.utils.js
@@ -1,7 +1,7 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.findEndpoint = void 0;
-function findEndpoint(api, method, path) {
-    return api.find((e) => e.method === method && e.path === path);
+function findEndpoint(api, method, path, alias) {
+    return api.find((e) => e.method === method && e.path === path && (alias === undefined || e.alias === alias));
 }
 exports.findEndpoint = findEndpoint;
diff --git a/node_modules/@zodios/core/lib/zodios.js b/node_modules/@zodios/core/lib/zodios.js
index 4190f45..5784163 100644
--- a/node_modules/@zodios/core/lib/zodios.js
+++ b/node_modules/@zodios/core/lib/zodios.js
@@ -137,10 +137,10 @@ class ZodiosClass {
         this.api.forEach((endpoint) => {
             if (endpoint.alias) {
                 if (["post", "put", "patch", "delete"].includes(endpoint.method)) {
-                    this[endpoint.alias] = (data, config) => this.request(Object.assign(Object.assign({}, config), { method: endpoint.method, url: endpoint.path, data }));
+                    this[endpoint.alias] = (data, config) => this.request(Object.assign(Object.assign({}, config), { method: endpoint.method, url: endpoint.path, data }, { fromAlias: endpoint.alias }));
                 }
                 else {
-                    this[endpoint.alias] = (config) => this.request(Object.assign(Object.assign({}, config), { method: endpoint.method, url: endpoint.path }));
+                    this[endpoint.alias] = (config) => this.request(Object.assign(Object.assign({}, config), { method: endpoint.method, url: endpoint.path }, { fromAlias: endpoint.alias }));
                 }
             }
         });

diff --git a/node_modules/@zodios/react/lib/hooks.js b/node_modules/@zodios/react/lib/hooks.js
index 8959b82..ceb8f0b 100644
--- a/node_modules/@zodios/react/lib/hooks.js
+++ b/node_modules/@zodios/react/lib/hooks.js
@@ -26,11 +26,11 @@ var ZodiosHooksClass = /** @class */ (function () {
             if (endpoint.alias) {
                 if (["post", "put", "patch", "delete"].includes(endpoint.method)) {
                     _this["use".concat((0, utils_1.capitalize)(endpoint.alias))] = function (config, mutationOptions) {
-                        return _this.useMutation(endpoint.method, endpoint.path, config, mutationOptions);
+                        return _this.useMutation(endpoint.method, endpoint.path, { ...config, fromAlias: endpoint.alias }, mutationOptions);
                     };
                 }
                 else {
-                    _this["use".concat((0, utils_1.capitalize)(endpoint.alias))] = function (config, queryOptions) { return _this.useQuery(endpoint.path, config, queryOptions); };
+                    _this["use".concat((0, utils_1.capitalize)(endpoint.alias))] = function (config, queryOptions) { return _this.useQuery(endpoint.path, { ...config, fromAlias: endpoint.alias }, queryOptions); };
                 }
             }
         });