Missing "Predefined Credential" for SeaTable in HTTP Request Node

[christophdb]

Dear community, dear developers of n8n,

I am Christoph from SeaTable. I am responsible for the SeaTable Community Node (https://www.npmjs.com/package/n8n-nodes-seatable). Some months ago, this community node was merged into core and my action Make an API Callwas removed.

My understanding is, that n8n does not want that every node includes an Make an API Callbut instead the users should use the HTTP Request Node. Is this correct?

If so, here is my question/problem.

Describe the problem/error/question

As you can see, there is no possibility to select SeaTable API as **Predefined Credential Type**.

Is there a way to include the SeaTable API? How is this option list populated?

What is the error message (if any)?

There is no error message. Just an option is missing.

Information on your n8n setup

• n8n version: 1.108.1
• Database: SQLite
• Running n8n via: Docker
• Operating system: debian 12

[Naufal_Fayyadh]

Hello christophdb, thank you for asking and welcome to the n8n community. Maybe i can help answer that.

From what i see in your question, you want to make an API Request to SeaTable, right?

I want to know if the SeaTable you’re referring to is like this? Because its already exists in node form and you can use it right away.

Maybe you can try it first, and if you encounter any issues, feel free to reply again. Hope this helps!

[christophdb]

Hello Naufal Fayyadh,

I am the developer of the SeaTable Node. In my community node, there was an Action Make API Request, but this action was removed as the code was merged into the n8n core.

The reason for that was: Make API Request in the SeaTable Node is not necessary. The HTTP-Node should be used instead.

Now my question is: why is SeaTable not available as option in the list of available authentication methods of the HTTP-Node?

The question is not about SeaTable, it is about how this list of authentication options is populated.

Best regards
Christoph

[Naufal_Fayyadh]

Aaa i get it now, thanks for clarifying. This may be the result of my opinion and research.

About how the HTTP Request “Credential Type“ list is populated, that dropdown is not auto-generated from every credential in n8n. It only shows credential types that are explicitly flagged as httpRequestAuth compatible in their credential class.

In other words, a credential has to implement the right interface so n8n knows how to inject it into HTTP headers/query params or auth flows.

So.. even though the SeaTable credential exists (for the SeaTable node), if it doesnt export itself as httpRequestAuth, the HTTP Request node wont list it.

Okay now, what this means for SeaTable. The original Make API Request action in your community node worked because you hard-coded how to apply SeaTable credentials. After merging to core, the philosophy is: use HTTP Request node instead of duplicating “make request“ actions in every node. But to make this smooth, your SeaTable credential definition must implement to standard httpRequestAuth extension. That way it will appear in the list, and users can reuse it directly.

And maybe i have a suggest if you want SeaTable to show up in HTTP Request. You can add the httpRequestAuth property in the SeaTable credential class. Define how to map credential fields (apiToken, baseUrl, etc.) into the request (headers, params). Once it done, rebuild, and SeaTable will appear as an option under Credential Type.

Thats all i think the information i can provide you with. I hope it answer your question.

[christophdb]

Dear Naufal,

1) General

thanks for your answer. In the meantime, I learned, that it would be sufficient to add this code to my SeaTableApi.credentials.ts. Probably this helps other node developers.

    authenticate: IAuthenticateGeneric = {
		type: 'generic',
		properties: {
			headers: {
			Authorization: '={{"Token " + $credentials.token}}',
			},
		},
	}; 

2) SeaTable specific case

Unfortunately, this does not work for SeaTable because this $credentials.token is not the final token. SeaTable has a logic that from this token (which is persistent) another token (with an expiration date) is calculated and then used for all API calls. For everybody who is interested, this is documented here in more detail: Authentication

That means, even if SeaTable appears in the HTTP-Request node, it will not work, because the code from the SeaTable Node is missing to get this other token.

Thanks for your help. Currently it is fine how it is.

Best regards
Christoph