Nutzung von custom-fields via API für Gitlab awork sync-> falscher Body

Developer Forum
1

Sehr geehrtes awork-Team,

ich plane, GitLab-Tickets mit awork-Aufgaben zu synchronisieren und nutze dafür Make.com. Die Erstellung neuer Aufgaben in awork basierend auf GitLab-Tickets funktioniert bereits. Nun möchte ich Updates bestehender Aufgaben umsetzen, stoße dabei jedoch auf folgende Probleme:

  1. Mapping mit Custom Fields: Ich habe die Custom Fields GitLab-Issue-ID und GitLab-Issue-Linkerstellt, um ihre IDs für das Mapping zu verwenden. Der API-Endpunkt https://api.awork.com/api/v1/projects/:projectId/customfielddefinitions liefert jedoch nur HTML-Code der Website statt des erwarteten JSON-Bodys. Ich erhalte jedoch Status 200.
  2. Best Practices: Gibt es eine empfohlene Methode zur Synchronisation bestehender GitLab-Tickets mit awork?
  3. Alternative Ansätze: Ist die Nutzung von Custom Fields sinnvoll oder gibt es bessere Lösungen?
2

Hi @jim.wilken ,

that sounds like a good approach. We are doing the same for our internal github integration. :wink:

The endpoint is the right one and should work. Could you paste the curl so i can check for typos? If you go to the settings page of a project you should see in the network tab in the browser the same call.

Best

Nils

3

Hey Nils! Here are the Informations. I have the rights to create, delete and modify customfields.

Input:

[
{
„url“: „https://api.awork.com/api/v1/projects/79641839-2bd2-4455-80ee-1b9564643771/customfielddefinitions“,
„method“: „GET“,
„headers“: [
{
„key“: „Content-Type“,
„value“: „application/json“
}
]
}
]

the Authorization is done by make.com directly. so no need for extra headers. works withother api endpoints just fine.

Output:

[
{
„body“: „\n<html lang= (…)
n\n\n“,
„headers“: {
„date“: „Fri, 03 Jan 2025 08:35:27 GMT“,
„content-type“: „text/html; charset=UTF-8“,
„transfer-encoding“: „chunked“,
„connection“: „close“,
„cache-control“: „no-store“,
„expires“: „0“,
„set-cookie“: [
„aw_lg=3xp9nO0=; domain=.awork.com; path=/; expires=Fri, 03 Jan 2025 08:45:27 GMT; httponly; Secure; SameSite=None“
],
„access-control-allow-origin“: „*“,
„strict-transport-security“: „max-age=31536000; includeSubDomains“,
„x-xss-protection“: „1; mode=block“,
„x-content-type-options“: „nosniff“,
„referrer-policy“: „origin-when-cross-origin“,
„x-frame-options“: „ALLOW-FROM https://teams.microsoft.com/“,
„permissions-policy“: „geolocation=()“,
„reporting-endpoints“: „csp-endpoint="/csp-reports?v=7&ngsw-bypass=true"“,
„content-security-policy“: "base-uri ‚self‘; frame-ancestors ‚self‘

(…)
},
„statusCode“: 200
}
]

4

@jim.wilken i replayed the call to the url provided and it works for me. What kind of html do you see?

6

the HTMl for the website :slight_smile:

„body“: "\n<html lang="en" translate="no">\n\n\n<link rel="preconnect" href="https://use.typekit.net" crossorigin><base href="/">\n \n <meta charset="utf-8"/>\n <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no"/

7

@jim.wilken we can still not find anything in our logging. Is the html you are seeing from our website or our awork webapp? can you send the complete html to nils@awork.com?

Best

Nils

8

And you once now wrote https://api.awork.com/api/v1/projects/:projectId/customfielddefinition this url, which is not correct (missing the ‚s‘). Can you double check which url you are using?

9

For the next person with the same problem: In make.com the paths needs to be relative without the base url. This was the problem in this case.

1 Like