Api kit initialisation issue

[shubh-elastic]

Issue: Receiving 404 Errors on SafeApiKit Requests

Description

I am encountering 404 errors when using the SafeApiKit with the following configuration:

SafeApiKit Version - ^2.4.5

const apiKit = new SafeApiKit({
  chainId: chainId,
  txServiceUrl: 'https://safe-transaction-linea.safe.global' // optional
});

As a temporary solution, I am making the API requests manually via fetch.

[dasanra]

Could you share more information?

Which endpoints do return 404?

[shubh-elastic]

i tried these proposeTransaction and getTransaction and thought there is some issue with apikit lib, but was the able to call apis directly using postman

[tinkrtailor]

@dasanra I am experiencing the same issue with the txServiceUrl for the Superchain safe on Redstone Garnet. The transaction service works in the browser and presumably when invoking directly but consistently getting NotFound for all invocations through the apiKit.

const apiKit = new SafeApiKit({
    chainId: 17069n,
    txServiceUrl: "https://transaction-redstone-testnet.safe.optimism.io",
 });
const serviceInfo = await apiKit.getServiceInfo();

Expected results: 200 OK Actual 404 NotFound

However the URL accessed by the apiKit method is working fine in browser: https://transaction-redstone-testnet.safe.optimism.io/api/v1/about/

[tinkrtailor]

@dasanra I am experiencing the same issue with the txServiceUrl for the Superchain safe on Redstone Garnet. The transaction service works in the browser and presumably when invoking directly but consistently getting NotFound for all invocations through the apiKit.

const apiKit = new SafeApiKit({
    chainId: 17069n,
    txServiceUrl: "https://transaction-redstone-testnet.safe.optimism.io",
 });
const serviceInfo = await apiKit.getServiceInfo();

Expected results: 200 OK Actual 404 NotFound

However the URL accessed by the apiKit method is working fine in browser: transaction-redstone-testnet.safe.optimism.io/api/v1/about

I found out what was causing this. When using the apiKit directly without a custom transaction service and a txServiceUrl

the constructor does a lookup based on the chainId and appends the /api to the url they find.

  constructor({ chainId, txServiceUrl }: SafeApiKitConfig) {
    this.#chainId = chainId

    if (txServiceUrl) {
      this.#txServiceBaseUrl = txServiceUrl
    } else {
      const url = TRANSACTION_SERVICE_URLS[chainId.toString()]
      if (!url) {
        throw new TypeError(
          `There is no transaction service available for chainId ${chainId}. Please set the txServiceUrl property to use a custom transaction service.`
        )
      }

      this.#txServiceBaseUrl = `${url}/api`
    }
  }

This causes a discrepancy between the shape of the urls that work for officially supported chains and others. In the supported case, the hostname is used and /api is appended to it. When directing to a non-supported chains' transaction service the the hostname and the '/api' path should be passed in as a parameter to the txServiceUrl.

TLDR: When using custom txServiceUrl make sure to have /api at the end of your url.

[dasanra]

@gunnigylfa you are right, when setting a custom service we are not adding the sub route where the service is hosted. Some developer asked for this because they wanted to use the domain root or a different path.

To avoid confusion in the future we will remove the automatic addition of /api also for the default ones so it's more clear that you should point to the full route where the service is hosted

@shubh-elastic could you please confirm this also fixes your issue?