# /api/devices/v2/deployments/device/deployments/next throws error

**URL:** https://hub.mender.io/t/api-devices-v2-deployments-device-deployments-next-throws-error/5555
**Category:** General Discussions
**Tags:** yocto
**Created:** [January 16, 2023, 7:47pm UTC](https://hub.mender.io/t/api-devices-v2-deployments-device-deployments-next-throws-error/5555 "2023-01-16T19:47:17Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![archibaldodlc](https://avatars.discourse-cdn.com/v4/letter/a/f17d59/32.png) [@archibaldodlc](https://hub.mender.io/u/archibaldodlc)
#### Post date: [January 16, 2023, 7:47pm UTC](https://hub.mender.io/t/api-devices-v2-deployments-device-deployments-next-throws-error/5555/1 "2023-01-16T19:47:17Z")

</div>

Hi, everyone! I hope everything goes well.

We have a Kubernetes cluster on AWS with Mender installed (recently upgraded to version 3.3.0 with the Helm package). It’s a Community Version and everything goes well, except for one thing that I cannot find in other topics.

There is a Yocto device (with mender version 3.3.1), that is connected to Mender Server (it works the terminal and, device information page), but when tries to use mender-client to check updates, the server throws the following error:

API-Gateway POD

```auto
{"ClientAddr":"10.127.3.235:26188","ClientHost":"10.127.3.235","ClientPort":"26188","ClientUsername":"-","DownstreamContentSize":21,"DownstreamStatus":404,"Duration":30000093878,"OriginContentSize":21,"OriginDuration":30000040914,"OriginStatus":404,"Overhead":52964,"RequestAddr":"mender.kwali.ai","RequestContentSize":101,"RequestCount":1922384,"RequestHost":"mender.kwali.ai","RequestMethod":"POST","RequestPath":"/api/devices/v2/deployments/device/deployments/next","RequestPort":"-","RequestProtocol":"HTTP/1.1","RequestScheme":"http","RetryAttempts":0,"RouterName":"deployments@file","ServiceAddr":"mender-gui:8080","ServiceName":"error-responder@file","ServiceURL":{"Scheme":"http","Opaque":"","User":null,"Host":"mender-gui:8080","Path":"","RawPath":"","ForceQuery":false,"RawQuery":"","Fragment":"","RawFragment":""},"StartLocal":"2023-01-16T19:09:03.880013648Z","StartUTC":"2023-01-16T19:09:03.880013648Z","entryPointName":"http","level":"info","msg":"","time":"2023-01-16T19:09:33Z"}

```

Deployments POD

```auto
2023-01-16T19:39:42.885398665Z time="2023-01-16T19:39:42Z" level=info msg="404 74μs POST /api/devices/v2/deployments/device/deployments/next HTTP/1.1 - Go-http-client/1.1" byteswritten=30 device_id=39c03e78-6f4a-4cbd-a400-a8c21e64a1c3 file=middleware.go func="accesslog.(*AccessLogMiddleware).MiddlewareFunc.func1" line=71 method=POST path=/api/devices/v2/deployments/device/deployments/next plan=enterprise qs= request_id=b5151cdf-39f0-4e8d-ba3e-bafbbbe23d94 responsetime=7.4855e-05 status=404 ts="2023-01-16 19:39:42.885111128 +0000 UTC" type=http

```

Is like if the Mender server cannot found the path “/api/devices/v2/deployments/device/deployments/next”. In the other side, the API v! for deployments works well.

The followings are the pods installed with Helm:

```auto
NAMESPACE NAME READY STATUS RESTARTS AGE
default api-gateway-657f58577b-w9cbr 1/1 Running 0 4d1h
default create-artifact-worker-6468c677bc-9w8mp 1/1 Running 0 4d1h
default deployments-5847bf4d74-ldlx8 1/1 Running 0 4d1h
default device-auth-86f6dc6cb8-n7dww 1/1 Running 0 4d1h
default deviceconfig-64b7d578f9-rxbqs 1/1 Running 0 4d1h
default deviceconnect-587d54b6fd-j2hkl 1/1 Running 0 4d1h
default gui-8655495768-d5xsw 1/1 Running 0 4d1h
default inventory-69f68bb849-pb96g 1/1 Running 0 4d1h
default iot-manager-6c5b485764-4tdrz 1/1 Running 0 2d22h
default nats-0 3/3 Running 0 263d
default nats-box-dd5fd77d5-pxzpp 1/1 Running 0 4d1h
default sonarqube-sonarqube-0 1/1 Running 0 4d1h
default useradm-6895d8dcf4-4p7kg 1/1 Running 0 4d1h
default workflows-server-7fb47fd544-gkhg6 1/1 Running 0 4d1h
default workflows-worker-69c7f788f9-pn44j 1/1 Running 0 4d1h

```

What could be happen?  
The path ‘/api/devices/v2/deployments/device/deployments/next’ is only for subscriptions plans?

Thanks in advance for the help.  
Regards,  
Víctor.

---

<div class="post-metadata">

### Author: ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)
#### Post date: [January 17, 2023, 3:41am UTC](https://hub.mender.io/t/api-devices-v2-deployments-device-deployments-next-throws-error/5555/2 "2023-01-17T03:41:45Z")

</div>

That’s correct, the v2 endpoint is only available in the Enterprise plan, and is used to implement dependency resolution for, among other things, binary delta updates. If it’s not available, the client will simply fall back to the v1 endpoint, so the message can just be ignored.

---

<div class="post-metadata">

### Author: ![archibaldodlc](https://avatars.discourse-cdn.com/v4/letter/a/f17d59/32.png) [@archibaldodlc](https://hub.mender.io/u/archibaldodlc)
#### Post date: [January 24, 2023, 8:46pm UTC](https://hub.mender.io/t/api-devices-v2-deployments-device-deployments-next-throws-error/5555/3 "2023-01-24T20:46:31Z")

</div>

Thanks, it works! Just for anyone who asks the same question, we had a Cloudfront (CDN) between the device and the Kubernetes cluster (where resides Mender) and when devices tried to connect, the Cloudfront responses with a 5XX error, not a 404 error like the “mender-api-connect” pod. So the device, I think, don’t try to connect again to v1 API. Disabling the Cloudfront for Mender solved the issue.

Thanks for you help @kacf !

Regards,  
Víctor.
